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PREFACE 


There  is  no  such  thin,',  as  a  oik-  man  show  in  the  lug 

profession.  Verily,  many  poop!  e  have,  given  mo  their  wi  1 1  ing  and  able 
support  during  this  project.  Principle  among  these  has  been  my 
the:; i s  committee.  L)r.  Gary  Laraont  as  chairman  provided  much 
guidance  as  this  ray  most  ambitious  project  began.  Being  a 
software  oriented  person  by  trade  and  hobby,  I  had  never  gotten 
much  involved  with  hardware  at  the  chip  level.  Dr.  John  Borky 
as  a  committee  member  provided  me  with  several  important  insights 
into  the  performance  of  various  chips  of  the  MOS  variety. 

Dr.  Walter  Seward,  the  other  committee  member,  helped  me  to  get  started  on 
the  DEC  System  10,  the  primary  tool  of  this  investigation. 

All  three  proved  quite  patient  with  my  naive  beginnings  and  later 
with  my  attempts  at  writing. 

Money  and  resources  must  come  from  somewhere  and  these  ware 
eagerly  provided  by  the  two  sponsors.  Mr.  John  If.  Acken; 

Sandia  National  Labs;  Dept  2113;  Albuquerque,  NM,  87185  gave 
me  much  of  his  time  and  a  gate  level  digital  systems  simulator 
which  he  maintains.  He  also  welcomed  me  to  his  home  and  office  during 
my  TDY  to  Sandia  Labs.  His  suggestions  as  to  what  needed  to  bo 
accomplished  provided  the  initial  framework  for  the  project. 

Capt.  John  B.  Rawlings;  AFWAL/AADE— 3 ;  WPAFB,  OH,  45433  was  the  other 
sponsor.  He  and  his  colleagues:  Mr.  Mike  Mills,  Lt  Eric  Smith,  Mr.  Rick 
Stormont,  Lt.  Joe  Tatmnn,  and  Lt.  Mike  Tebo  gave  constant  feedback  on  the 
real  world  requirements  of  Computer-Aided— Design.  They  were  always  ready 
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with  lh. -li  t  Line  and  I  Lowsli  i  p.  dipt.  Rawlings’  in  i  t  La  I: !  ve.s  <it  AF1T 

opened  tin.-  door  for  thin  investigation.  Ills;  division.  headed  by 
by  I.TO .  liny  In:.  :-.iW  !  i.  ;  It  •  ,’.i  i  )  h  L  I  i ly  of  tin.*  1  ).X  By  .steia  10 

aiul  a  wall  equiped  o  If  In.  e . 

The  library  services  of  At  IT  tvre  superb.  Mrs  Molly  Bustard 
always  assisted  as  ln:r  shelves  were  gradually  emptied.  She  helped  in 
finding  books  and  in  long  term  withdrawals.  Mr.  Stan  Boyd  gave  his 
excellent  aid  to  the  filling  of  requests  for  quite  a  number  of 
backdated  journal  articles.  What  our  library  did  not  have,  he  searched 
the  world  for. 

During  their  inception,  many  projects  benefit  from  the  counseling  of 
people  who  have  a  good  feel  for  what  will  be  acceptable  and  what  will  not. 
In  this  regard  my  thanks  go  out  to  Dr.  Tom  llartrum,  Dr.  Kenneth  Melendez, 
and  Dr.  Jim  Rutledge. 

Not  to  go  unmen t Lotted  are  two  very  fine  technicians  in  AFIT's  labs. 

Mr.  Dick  Wager  and  Mr.  Dan  Zambon  saw  to  it  that  books  and  equipment  held 
by  their  department  were  made  available.  They  also  gave  Informative 
discussions  on  the  acntal  use  of  MOS  chips. 

Also  there  is  Mr.  Mike  Culp,  a  high  school  student  who  studied 
computer  programming  under  my  tut.eladge.  He  produced  several  of  the 
descriptive  drawings  that  were  needed. 

Finally,  but  certain] ly  not  in  the  least  Is  my  dear  friend  and  colleague 
Capt. .  Nadine  Levine.  Her  intuition  helped  me  to  solve  the  several  problems 
which  bedevil  thesis  students.  Her  never  ending  encouragement  made  doing 
this  thesis  much  easLer. 

To  all  of  these  people  I  owe  my  sincere  gratitude. 
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ABSTRACT 


-r-Vn.ilo  j>.i  1 e  1  evt  ]  .uni  register  «  ranis  for  lov<*'|  digital  si  Tula  Lor; 

exist,  ona  can  not  easily  in t  .grate  the  two  duo  to  their  inherent 
limitations.  A  given  simulation  can  not  be  described  partially  in  gate 
level  and  partially  in  a  higher  level.  A  solution  is  to  create  a 
functional  level  preprocessor  and  a  library  of  functional  device 
models  linked  to  a  gate  level  simulator's  input  language.  Tills  permits 
the  mixing  of  behavioral  .node Is  with  gate  level  models  in  the  same  system 
structure.  The  combination  of  processes  (element  models  or  primitives) 
and  their  structure  (interconnections)  can  be  exercised  all  at  one  time 
during  a  single  simulation  session. ^From  the  start,  there 
came  forth  an  obvious  method  .•hid.  could  be  used  to  intermix 
the  several  levels  of  modeling  (*) . 

Two  separate  pieces  of  software  were  written  to  implement  a  specific  solution 
to  the  above  stated  situation.  SISL,  Structural  Interface  to  the  Salogs 
Language  was  created.  This  is  a  functional  level  preproc.esor  to  SALOGS 
(SAndia  LOGic  Simulator)  which  is  an  eight. -state,  MOS,  gate  level 
digital  systems  simulator.  SISL  will  accept  functional  level  systems 
descriptions  and  convert  them  to  a  form  acceptable  to  SALOGS. 

The  other  effort  was  the  building  of  a  functional  level  modeling 
library.  This  library  consists  of  three  behavior  models;  a  4—1 6  decoder, 
a  2 04 C  X  8  ROM,  and  a  256  X  8  RAM.  Those  models  are  designed  to  be  used 
in  a  functional  .level/gate  level  model  of  a  digital  system  and  will 
link  to  the  SAIv'OS  run  time  system.  Together,  these  two  programs.  (SISL 
and  the  modeling  library)  provide  the  easy  use  of  the  top-down  approach 
to  digital  system  design.  Thus,  the  project's  culmination. 

(*)  S.o  Chapters  1  and  7  for  mare  on  the  hierarchy  of 
digital  systems  modeling. 
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CH  1.  INTRODUCTION 


Gate  level  simulation  along  with  register  transfer  level  descriptions 
has  been  the  bread  and  butter  of  computer  aided  logic  design  [H2,86]. 

Until  the  present  time,  eight-state,  gate  level  simulation  of  digital 
devices  has  sufficed  for  the  development  of  most  logic  circuits.  The  eight 
states  are:  low  level,  undefined,  high  impedence,  high  level,  negative  slope, 
transient  undefined,  transition  to  high  impedence,  and  positive  slope  [A 1 ,12]. 

In  the  past,  many  simulator  packages  have  been  restricted  to  gate  level 
models  because  the  state  of  the  art  would  not  support  more  general  types 
of  modeling  [S9,25].  This  restriction  has  caused  many  problems  as  the 
state  of  the  art  in  digital  device  construction  has  improved. 

PROBLEM 


One  of  the  major  problems  of  digital  simulation  is  that  large  systems  are 
prohibitively  difficult  to  describe  and  simulate  at  the  gate  or  register 
difficult  to  describe  and  simulate  at  the  gate  or  register  transfer  levels, 
transfer  levels.  The  desire,  therefore,  was  to  create  a  new  level  of 
simulation  called  the  functional  level  [H2,86]. 

At  this  level  the  designer  can  specify  subsystems  such  as  ROM,  RAM, 
busses,  shift  registers;  in  short,  logical  devices  of  arbitrary  complexity. 
Functional  level  modeling,  as  addressed  by  this  investigation,  is  meant 
occurs  during  the  "...circuit  description  language..."  phase  of  the  typical 
CAD  (Computer  Aided  Design)  run. 
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Tile  modeling  and  simulation  of  a  digital  system  follows  a  pattern 
which  enhances  the  use  of  machine  assistance.  Material  developed  via 
simulation  can  be  used  in  t lie  actual  implementation  as  well.  Fig  CHI-1 
[C 8 , 292 ]  depicts  the  simulation  proces-.  The  intent  is 

to  affect  only  the  indicated  phase  and  to  let  the  rest  of  the  simulation 
to  proceed  as  if  no  modifications  had  taken  place.  At  this  phase 
functlonal/gate  level  models  are  described,  not  just  gate  level  models  as 
in  the  past.  SISL  doe9  its  work  at  this  node  and  SALOGS  picks  up  the 
process  at  the  "...gate  level  simulation..."  node. 

GOAL 


It  should  be  possible  to  allow  computer  designers  to  focus  on  certain 
portions  of  a  digital  system's  logic  while  ignoring  details  of  other 
portions.  Designers  should  be  able  to  "black  box"  certain  portions  of  a 
big  system.  At  times  it  will  not  be  known  what  the  future  contents  of  a 
module  will  be,  only  that  it  will  have  to  exist  in  the  system. 

The  results  of  this  study  should  allow  the  designer  to  choose  which 
blocks  to  describe  at  the  gate  level  and  which  to  describe  at  the  functional 
level.  A  person  would  thus  be  encouraged  to  follow  a  top-down  design 
methodology.  A  preprocessor  to  the  gate  level  simulator  should  handle  the 
connections  between  the  two  levels  of  descriptions. 

It  is  possible  to  develope  software  which  can  give  a  great  deal  of 
help  to  the  designer  during  any  attempts  at  higher  level  models  and 
simulations. 
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APPROACH 


The  above  goal  was  met  by  designing  a  library  of  functional 
level  subroutines.  A  functional  level  preprocessor  was  also  developed.  The 
preprocessor  accepts  digital  descriptor  input  and  converts  it  to  a  form  which 
logically  links  the  subroutine  library  to  the  input  language  of  a  commonly 
used  gate  level  digital  simulator.  Such  a  common  industrial  simulator  is 
found  in  SALOGS,  an  eight-state  computer-aided-design  (CAD)  system  developed 
at  SANDIA  LABS  [C2, 1 ]  [Appendix  D] . 

Salogs  allows  the  user  to  describe  models  composed  of  MOS  gate  level 
primitives  (AND,  OR,  etc.)  and  to  perform  simulations  using  those  models. 

It  will  also  do  fault  analysis.  Another  feature  is  a  capability  to  accept 
subroutines  which  are  callable  as  modeling  primitives. 

This  approach  to  the  realization  of  the  goal  must  necessarily  be 
clearly  defined  as  to  what  may  be  expected  of  it. 


SCOPE 


The  preprocessor  mentioned  above  does  not  convert  functional 
descriptions  into  gate  descriptions.  It  does,  however,  create  the 
logical  linkages  to  the  SALOGS  input  language  so  that  pin  connections, 
device  names,  and  other  parameters  required  by  SALOGS  are  made 
consistent  with  the  users'  gate  level  portion  of  the  overall  system  being 
modeled.  The  preprocessor  delivers  two  outputs  based  on  the  functional  level 
description  it  receives:  functional  identifiers  required  by 
SALOGS  and  a  model  specifying  the  overall  functional  system.  From  these 
outputs,  the  preprocessor  creates  a  file  of  functional  descriptors 
which  can  be  appended  to  the  gate  level  portion  of  the  users'  description. 

The  user  must  identify  his  interconnections  to  the  preprocessor's 
circuit.  Since  SALOGS  allows  the  linking  of  subroutines  to  its  own 
code,  no  modifications  have  to  be  made  to  SALOGS  itself.  The  software 
is  run  in  batch  mode  due  to  the  extended  amount 
of  wall  time  and  core  required  by  the  SALOGS  software  (*).  To 
ensure  portability,  the  project  was  done  in  ANSI  66  standard  FORTRAN  IV, 
the  same  as  SALOGS  itself. 

The  library  of  functional  models  is  written  to  deliver  useful  information 
to  the  designer.  These  models  (which  account  for  all  eight  states), 
under  specific  inputs  will  indicate  that  an  unspecified  input  has 
occured  rather  than  behave  as  the  real  circuit  would. 

There  are  some  o  Ther  ideas  and  features  which  should  be  presented. 

These  have  to  do  with  the  development  of  the  software  and  techniques 
of  functional  level  modeling. 


(*)  Wall  time  varies  according  to  how  many  Jobs  are  currently  being 

handled  by  the  computer  system.  Core  is  constant  at  around  200K  for 
each  program  in  the  SALOGS/SISI,  series. 
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FOR  FURTHER  DISCUSSION 


The  body  of  tills  thesis  is  concerned  with  three  ideas:  digital 
modeling  in  general,  the  methods  of  functional  modeling,  and  the 
internal  workings  of  the  SISL  preprocessor. 

Chapter  2  gives  an  introduction  to  some  of  the  basic  ideas  used  by 
those  who  actively  engage  in  the  simulation  of  digital  systems. 

Some  approaches  to  the  subject  are  generally  accepted  in  the 
simulation  community  as  standard  and  this  chapter  reviews  these. 

Chapters  3  and  4  discuss  the  top-down  method  of  digital  system  design 
and  its  specific  application  to  this  project. 

Chapters  5  and  6  present  some  general  methods  of  creating  behavioral 
models  of  digital  devices.  These  were  developed  for  use  in  this  investigation 
and  are  applied  to  the  modeling  library. 

In  Chapters  7  and  8  one  will  find  an  overview  of  digital  system 
representation  levels  and  a  few  of  the  languages  used  to  work  at  one 
or  more  of  those  levels.  SISL  is  an  application  of  the  ideas  found  in 
these  other  digital  system  description  languages. 

The  thesis  closes  with  the  summary  and  conclusions  found  in 
Chapter  9. 

These  presentations  are  supported  by  an  Appendix  and  Glossary.  In  the 
Appendix  will  be  found  users'  guides  to  the  various  software,  listings  of  the 
SISL  and  modeling  programs,  sample  runs,  and  flowcharts.  The  Glossary  defines 
the  specific  terms  used  and  will  clear  up  any  confusion  as  to 


their  meaning 


CH  2.  AN  OVERVIEW  OK  THE  COUl'll  l' KR  AIDED  DESIGN  OF  DIGITAL  SYSTEMS 


This  chapter  reviews  some  of  the  basic  approaches  to  digital  systems 
simulation.  It  begins  with  a  definition  of  what  computer  aided  design 
should  accomplish  and  goes  on  to  the  general  ways  in  which  one  may 
employ  simulation  techniques  for  digital  systems.  A  summary  provides 
information  on  the  current  uses  of  simulation. 

DISCUSSION 


Because  of  the  complexity  and  economics  of  today's  digital  systems, 
a  design  tool  is  needed  that  will  allow  the  error  free  analysis  and  testing 
of  circuit  Implementations  (*).  This  tool  should  not  require  the  physical 
realization  of  the  circuit.  Such  a  tool  has  been  found  in  the  form 
of  a  computer  running  a  piece  of  software  which  will  exercise  a  digital 
system  that  has  been  described  in  the  input  to  that  software.  Programs  of  that 
nature  performing  computer-aided-design  (CAD)  permits  the  digital  designer 
to  submit  his  circuit  ideas  to  strict  and  nearly  complete  simulation  and 
analysis  without  having  to  physically  construct  the  hardware. 

Many  such  simulation  tools  exist  today  [B2,l]  [C2,l]  [VI, 1]  [V3,l]. 

(See  the  Bibliography  for  papers  on  specific  languages.)  They  provide 
an  entrance  to  the  solution  of  modeling  problems.  Most  of  the  larger 
companies  in  the  computer  industry  are  involved  in  CAD  research.  Among 
these  is  IBM  [B1 , 20] . 


(*)  Unless  otherwise  noted,  the  references  for  this  chapter  are  found 
in  the  works  by  Acken  and  Case  listed  in  the  bibliography. 
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The  simulation  of  a  digital  system  is  the  description  of  the 
system  model  in  an  appropriate  computer  language  along  with  the 


computer's  experimentation  with  that  model.  Through  the  use  of  CAD 
software,  a  circuit  description  and  operating  parameters  are  taken  as 
input,  with  experimental  and  statistical  results  of  the  circuit 
simulation  as  output. 

TWO  GENERAL  TYPES  OF  SIMULATION 


There  are  two  general  types  of  logic  simulation:  True-Value  Analysis 
and  Fault  Simulation.  A  designer  using  True-Value  Analysis  is  judging 
the  circuit's  ability  to  perform  according  to  the  original 
specification  of  the  design  criteria.  Fault  Simulation  is  employed  to 
observe  system  operation  under  various  forms  of  circuit  flaws. 

(TRUE-VALUE  ANALYSIS)  In  its  most  fundamental  form,  True-Value  Analysis 
is  the  acceptance  of  the  logical  description  of  a  circuit,  the  application 
of  logical  values  (l's  or  0's)  to  the  circuit's  inputs,  and  delivering  as 
output  the  Boolean  result  of  the  combination  of  circuit  and  inputs. 

An  extension  of  simple  Boolean  modeling  in  terms  of  the  binary  values 
1,0  is  to  add  a  state  to  the  simulation  called  a  DON'T  KNOW  or 
UNDEFINED  (or  *).  This  unknown  logic  state  is  distinct  from  a  DON'T  CARE 
whose  logic  level  can  be  either  1  or  0  with  no  affect  on  the  operation 
of  the  circuit. 

Given  smaller  and  smaller  time  steps,  the  time  it  takes  a  voltage  to 
rise  to  the  1  level  or  fall  to  the  0  level  becomes  important.  As  digital 
circuits  become  faster  and  faster,  the  timing  issue  becomes  more  important. 
Thus,  more  advanced  simulators  use  three  extra  states: 

D,  negative  slope;  U,  positive  slope;  and  X,  transition  undefined. 


Six-state  simulation  allows  Ulie  computer  modeling  of  very  fast 
digital  systems  without  worrying  about  the  particular  technology  to 
be  used  in  the  actual  system  construction.  Some  simulators  (SALOGS  for  one) 
do  incorporate  MOS  technology  in  their  software.  These  simulators  employ 
two  additional  states  result  in  an  eight-state  simulation.  Those  two 
states:  H,  high  impedance;  and  A,  transition  to  high  impedance  are  used 
to  simulate  a  device  being  effectively  off-line. 

Digital  simulators  which  model  various  other  technologies 
usually  have  the  ability  to  be  set  for  four-  or  eight-state  mode. 

In  four-state  mode,  the  model  operates  using,  high,  low,  undefined, 
and  high  irapedence.  Eight-state  mode  simulates  using  the 
added  states  of  negative  slope,  positive  slope,  transition  undefined, 
and  transition  to  high  impedence  (See  Appendix  D). 

(FAULT  SIMULATION)  Fault  simulation  is  performed  to  derive  a  set  of  input 
signals  which  can  then  be  used  as  stimuli  to  test  the  functioning  of  a  logic 
network.  These  signals  form  a  test  pattern  which  can  be  auutomatically  generated 
by  the  simulation  software.  When  these  signals  are  placed  on  a  circuits'  input, 
they  allow  the  detection  of  certain  defects  [T 3,38] .  Usually,  single  "stuck-at" 
fault  modeling  is  used  due  to  the  difficulties  of  multi-fault  modeling. 

In  this  method,  only  one  defect  is  assumed  and  It  is  a  particular 

signal  being  "stuck  at"  or  a  "never  changing"  value.  Either  one  of 

the  module's  outputs  is  stuck  or  one  of  its  inputs  is  stuck.  There  are 

four  ways  to  simulate  a  fault:  fail-all  simulation,  which  will  fail  all  outputs 

one  at  a  time;  parallel  fault  simulation,  which  simulates  several  faults  at  once 

deductive  fault  simulation,  which  lists  faults  which  cause  a  change  in  the 

output  of  a  given  module  compared  to  the  unfaulted  circuit;  and 

concurrent  faulting,  which  only  simulates  the  parts  of  the  faulted 

circuit  whose  inputs,  outputs,  or  states  do  not  agree  with  the 

unfaulted  circuit. 
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SUMMARY 


Since  it  has  become  so  expensive  to  build  anti  test  unproven  hardware, 
computer  simulation  of  digital  circuits  is  being  employed  more  often  by 
the  military  and  industry.  Since  design  correctness  can  be  verified 
without  actual  hardware  realization,  the  cost  of  design  and  implementation 
is  cheaper  than  it  would  be  if  computer  simulation  were  not  used. 

Simulators  make  it  possible,  without  risk  to  a  physical  circuit,  to 
study  and  experiment  with  a  system  or  subsystem.  (There  is,  however,  a 
certain  financial  risk  associated  with  committing  a  facilities' 
resources  to  the  simulation  task  [S9,23].)  Simulators  make  fine  pedagogical 
devices  for  teaching  both  students  and  practitioners  the  variations  of 
the  design  and  analysis  of  digital  systems.  Perhaps  one  of  the  most 
important  benefits  from  an  engineering  point  of  view  is  that  they 
allow  systems  to  be  exercised  under  expanded,  compressed-  or 
normal  timing.  Overall,  they  permit  the  designer  to  judge  his  designs 
conceptually  without  actually  having  to  build  them. 

Work  on  such  design  aids  has  been  pursued  by  Sandia  Laboratories 
(Albuquerque  NM) ,  the  Avionics  Laboratory  of  the  Wright  Aeronautical  Labs 
and  A  r  Force  Institute  of  Technology  (Dayton,  OH),  to  name  a  few.  As  more 
and  more  standard  models  of  low  level  devices  are  created,  digital  modeling  at 
higher  and  higher  levels  becomes  possible,  thus  overcoming  the  bottleneck  of 
man-years  and  computer  resources  required  to  create  simulations  of  large 
scale  digital  systems. 
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CH  3.  THE  BUILDING  OF  A  SYSTKM  USING  FUNCTIONAL  MODLLS 


A  digital  system  is  not  simply  created  in  its  final  form.  It  is  not 
usually  possible  to  design  a  working  product  on  the  first  attempt.  Several 
systems  are  developed  in  the  course  of  a  development  effort.  These  range 
from  the  interconnection  of  a  few  high  level  subsystem  blocks  to 
the  detail  of  a  gate  level  or  lower  model.  This  chapter  introduces  the 
reader  to  the  process  of  going  from  the  higher,  undetailed  modeling 
level  to  the  lower,  detailed  level. 

THE  GATE  LEVEL  AND  BLACK  BOX  BEGINNING 


The  desire  to  intermix  gate  and  functional  models  derives  from  the 
hierarchy  of  a  top-down  approach  to  digital  systems  simulation.  In  this 
method,  one  begins  with  an  undetailed  viewpoint  of  the  desired  system. 

This  viewpoint  is  in  terms  of  a  few  general  blocks.  As  the  modeling 
effort  goes  on,  these  blocks  are  broken  down  into  more  detailed  sub-blocks. 
Finally,  each  sub-block  is  defined  by  progressively  more  complex  units 
until  the  desired  level  of  detail  is  achieved. 

Thus,  the  black  box  is  a  part  of  a  model  which,  as  yet,  does  not  perform 
as  it  ultimately  will.  It  can  be  connected  to  more  detailed  portions  such 
as  a  block  described  in  gate  level  detail.  There  is  a  certain  technique  to 
using  this  mix  when  simulating  with  SALOGS. 
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USING  THE  BLACK  BOX 


SALOGS  has  the  capability  to  "SET"  the  value  of  any  of  its  nodes. 

(For  more  discuss  Lon  on  SALOGS  see  the  SALOGS  USERS  GUIDE  in  the  Appendix.) 
Such  nodes  will  retain  their  set  value  regardless  of  system  operation. 
Therefore,  the  designer  can  allow  the  black  box  to  either  deliver  some 
default  output  for  any  input  or  deliver  a  SALOGS  set  output.  The 
model  may  then  be  studied  under  various  conditions  which  may  be 
eventually  produced  by  the  future  contents  of  the  box.  The  default 
outputs  can  be  used  to  flag  the  fact  that  the  box  would  have  had  some 
effect  on  the  systems'  operation. 


EXPANDING  THE  BLACK  BOX 


Gradually,  decisions  will  be  made  as  to  the  required  output  of  the 
box  given  certain  inputs.  Now  the  functional  model  may  be  expanded  to 
produce  that  output  when  the  stated  inputs  occur.  A  default  to  some 
flagging  output  (such  as  undefined)  can  be  arranged  for 
non-specif led  inputs. 

As  more  data  is  gathered  and  greater  detail  is  developed,  the 
black  box  becomes  a  true  functional  model  performing  very  nearly  as 
its  gate  level  counterpart  would.  It  has  the  advantage  of  using  less  core 
and  time  to  run  and  it  ignores  some  of  the  unwanted  or  unneeded  detail 
attendant  to  gate  level  models.  It  can  be  expanded  to  any  desired  level  of 
detail  depending  on  resources  and  the  needs  of  a  given  simulation. 
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Cli  4.  ST  Mill,  AT  I  NG  BI— DT RENT  TONAL  I, INI'S 


SALOGS,  l hi;  gate  level  uadel iny  software,  has  some  particular  requi  rement  ; 
when  bi-directional  lines  are  called  for.  This  chapter  introduces  the 
background  s  of  such  linos  and  continues  with  the  detailss  of  their  simulation 
in  SALOGS. 

INTRODUCING  BI-DIRECTIONAL  LINES 


As  chip  manufacturers  have  heaped  complexity  upon  complexity,  the 
number  of  pins  necessary  for  I/O  has  increased.  Fourty  pins  has 
generally  become  the  acceptable  maximum  standard  but  some  chips  would 
require  more  than  that.  Because  of  this,  certain  pins  have  been  designed 
to  carry  data  in  both  directions.  These  pins  thus  make  it  possible  to  have 
fewer  connections  to  a  chip  while  keeping  the  original  number  of  options. 

The  issue  of  bi-directional  lines  should  be  addressed.  If  a  design  aid 
is  to  maintain  its  capability  to  deal  with  state  of  the  art  systems,  it 
must  accomodate  the  devices  which  make  up  those  systems. 
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SALOGS  SIMULATION  OF  III-IUKKCT  IOUAL  LINKS 


SALOGS  itself  will  not  nl  low  the  direct  use  of  b  i-d  i  reet  ional  linos.  Nodes 
are  either  input  or  output  but  not  both. 

Without  modification  to  the  SALOGS  package,  it  is  not  possible  to 
truely  simulate  bi-directional  lines.  However,  by  using  a  buss 
model  and  splitting  each  two-way  line  into  one  input  and  one  output  line, 
one  can  still  model  devices  with  such  lines.  Along  with  this,  one 
can  incorporate  timing  and  clocking  and  delay  parameters  in  the  buss. 

(The  behavioral  models  themselves  do  not  contain  these  parameters.) 

Such  a  splitting  out  of  bi-directional  lines  has  not  proven  to  be  a 
drawback  to  the  modeling  effort  of  this  investigation.  The  RAH  and  ROM 
models  to  be  discussed  later  use  line  splitting. 

The  buss  model  also  solves  a  problem  caused  by  the  way  SALOGS  updates 
nodes.  Nodes  are  updated  sequentially,  one  at  a  time  each  time  step.  When 
bi-directional  lines  are  used  the  wrong  item  could  be  updated  first.  Let  us  say, 
for  instance,  that  the  CPU  is  talking  to  the  RAH.  If  the  RAH  is  updated  first 
then  the  CPUs'  input  is  not  properly  considered.  The  buss  is 
last  to  be  updated  so  that  the  RAM  and  CPU  get  correctly  updated  in 
the  next  time  step.  SALOGS  is  caused  to  update  the  buss  last  when  the  user 
lists  the  buss  last  in  a  system  description. 

The  buss  model  could  be  expanded  to  also  handle  buss  contention.  While 
SALOGS  can  easily  handle  the  fanout  of  output  lines,  it  can  not 
describe  the  fanin  of  input  lines.  Only  one  output  node  can  talk  to 
any  given  input  node  at  any  one  time.  If  input  to  a  given  node  can  come 
from  more  than  one  output  node,  some  buss  control  must  take  place. 

A  SALOGS  bi-directional  buss  can  be  written  as  a  behavioral  model 
to  handle  several  simulation  requirements.  The  most  important  of  these 
are  two-way  lines.  These  are  followed  hy  timing,  clocking,,  and  delay 
parameters.  One  final  Item  is  the  description  of  a  buss 


contention  controller. 


CH  5.  CRKATTMC  A  CHIPS'  I'.KIIAVIOUAL  MODI;:, 


Sever  il  I  in  ■  m  mist  be  considered  when  writing  software  v;h  Leh  describes 
a  behavioral  model.  It  is  not  a  straightforward  task  to  construct  such  a 
program.  Presented  in  this  chapter  are  the  methods  used  and  the  considerations 
taken  in  creating  the  behavioral  modeling  library. 

COMPLEXITY  VS.  DETAIL 


Many  are  the  ways  to  create  a  behavioral  model.  Each  method  has  its 
own  advantages  and  drawbacks. 

Let  D=  detail  of  simulation 
C*»  device  compexity 

K=  a  constant  representing  computer  and  human  resources 
Then  D  *  C  =  K  would  be  an  excellent  conceptual  formula  for  describing 
the  various  limitations  to  face  when  modeling  a  digital  system  (*). 

The  overall  goal  of  modeling  is  to  simulate  in  great  detail  very  complex 
devices  while  minimizing  core  and  human  involvement. 

These  ideas  are  very  much  at  odds  with  each  other.  As  the  complexity 
of  the  device  increases,  the  limitations  of  computer  and  human  resources 
prevent  the  simulation  of  a  great  amount  of  detail.  Conversely,  if  a  large 
amount  of  detail  is  required  the  same  problem  will  not  allow  the  modeling 
of  complex  devices.  As  the  available  human  and  computer  resources 
increases  or  decreases  so  can  detail  and  complexity  to  a  proportional  degree. 

The  following  sections  review  several  methods  of  creating  behavioral 
models.  These  were  developed  in  the  course  of  the  attempts  made 
te  cre.it>1  ■  .'iiomio.il  yet  detailed  behavioral  modeling  library.  There 
will  he  ,i  ,  ..  r  tradeoff  evident  in  that,  while  a  particular  method  may 

be  easy  to  implem  nr  ,  it  may  not  always  yield  an  economical  or  otherwise 
us.th  ]  e  mode  1  . 

(*)  This  formul at i on  was  originally  suggested  by  the  sponsor,  Rawlings. 
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SIMl'Lf-  TABLR  I)R1 VLN  MODIILS 


The  fastest  way  to  derlv*  .1.1  output  from  an  input  it;  to  imp  the 
input  to  a  location  in  a  table  which  contains  the  corresponding  output. 

It  is  helpful  to  assign  a  number  to  each  of  the  eight  states  that  any  given 
node  may  attain: 


SALOGS  Assignment 

FORTRAN  Assignment 

State 

0 

1 

0 

False 

1 

2 

* 

Undefined 

2 

3 

H 

High  Impedance 

3 

4 

1 

True 

4 

5 

D 

Downward  Slope 

5 

6 

X 

Transient  Undefined 

6 

7 

A 

Transition  to  High  Impedance 

7 

8 

U 

Upward  Slope 

When  SALOGS  fixes  a  node  value  it  uses  these  assignments. 

These  must  be  converted  to  the  FORTRAN  assignments  for  array  table 

access.  As  an  illustration,  consider  a  box  which  has  two  inputs  and  two  outputs. 

The  inputs  can  be  modeled  using  a  two  dimensional  table  which  is  8  X  8.  The 

output  lines  are  modeled  the  same  way  only  with  an  8**2  X  2  table.  There  are 

8**2  output  possibilities  due  to  the  8X8  possible  input  arrangements.  The 

following  is  an  example  of  how  the  array  tables  are  used  to  model  the 

box.  Let  input-line-1  be  In  state  A  and  input-line-2  be  in  state  U. 

This  will  cause  a  certain  resulting  output.  SALOGS  will  represent  the 
input  event  as  6,7.  The  input  table  will  be  accessed  using  (6+1, 7+1). 

Contained  in  that  location  is  the  row  of  the  output  table  which  holds 


the  required  output  line  values.  Each  column  of  the  output  array  hold:;  a 

state  for  a  dee; Lgnated  output  Hue.  In  general  term:;,  an 

8X8  x...x  8  Input  table  naps  t a  an  8**N  X  K  output  table  where: 

N!i  //  input  line;; 

K=  #  output  lines 

If  K=l,  then  the?  value  found  in  the  input  table  is  the  state  of  the 
output  line.  States  assigned  to  output  lines  are  SAT.OGS  assignments. 

In  this  case,  due  to  the  stated  behavior  of  the  box,  there  may  not  be 
8**2  unique  output  arrangements.  If  that  proves  true,  the  output 
table  may  be  shrunk  accordingly  to  an  M  X  2  array;  where  M  is  the  number 
of  unique  outputs.  M's  maximum  value  is  8**2.  The  input  table  remains  the 
same  size,  but  any  given  location  could  hold  the  same  value  as  another. 

In  general,  there  is  a  maximum  of  8**Z  unique  outputs;  where 

Z  is  the  number  of  output  lines.  Also,  it  may  not  matter  which  is  input-line- 1 
and  which  is  input-line-2.  In  other  words,  (input-line-1  +1 , input-line- 2  +1) 
may  always  yield  the  same  value  as  (input-line-2  +1 , input-line- 1  +1). 

In  that  case  only  the  upper  or  lower  triangle  of  the  input  matrix  would  be 
needed.  In  FORTRAN,  though,  it  is  not  possible  to  dimension  a  triangular 
array.  If  carefully  documented,  the  unused  portion  of  the  input 
table  could  be  applied  to  some  other  activity,  thereby  achieving  a  savings 
in  core. 

Once  the  output  array  has  been  accessed,  one  needs  to  find  there  the 
values  which  correctly  define  the  devices  behavior. 


21 


(DERIVING  THE  OUTPUTS )  The  next  question  involves  exactly  what  outputs  arc 
required  from  all  the  possible  Input  combinations.  For  an  original  circuit,  a 
knowledge  of  th«*  chips'  technology  and  configuration  would  he  the  key.  For  j> r • 
manufactured  circuits,  there  is  available  an  Industrially  proven  and  tested 
gate  level  modeling  package,  SALOGS.  Its  primitives  (AND,  OP.,  NOR,  etc.) 
are  fully  defined  MOS  models.  They  will  deliver  a  correct  output  given 
any  combination  of  the  states  as  input.  With  this  package  one  could  model 
a  device  at  the  gate  level,  apply  all  possible  input  combinations,  and 
thus  receive  a  corresponding  list  of  outputs.  This  list  can  then  be  used 
to  load  the  output  table.  The  gate  model  need  be  run  only  once.  Its  results 
can  be  held  in  off-line  storage  until  the  data  is  needed  to  load  the 
I/O  arrays. 

A  problem  with  the  above  technique  is  that  a  gate  level  model  taken 
from  a  data  book  is  only  a  logical  model,  not  an  operational  one.  Also, 
it  would  be  extremely  difficult  to  model,  say,  a  64K  RAM  at  the  gate  level. 

So  there  are  limitations  to  just  how  far  one  can  go  with  this  method. 

Too,  as  the  chip  becomes  more  complex,  a  lot  of  core  is  required 
to  represent  the  I/O  tables.  (A  five  input  OR  gate  requires  8**5  array 
locations.)  On  the  other  hand,  not  much  time  is  used  in  the  simple 
array  mapping  process.  These  problems  can  be,  in  part,  overcome  by  the 
following  technique. 
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TABLE/ EQUATION  DRIVEN  MODELS 


If  a  certain  ft  I  .-u  >•  on  any  ii.qeit  lino  always  imu:;**.;  the  s  awe 
output  arrangement ,  t!ie  I/O  tables  can  be  collapsed  accordingly. 

Equations,  both  arithmetic  and  logical,  would  be  then  required  to 

recognize  the  states  which  cause  fixed  outputs.  Other  arguments 

would  be  needed  to  map  the  other  input  combinations  to  the  reduced  tables. 

For  example;  consider  the  five  input  OR  gate  which  used  8**5  array  locations. 
Employing  a  combination  of  equations  and  tables  tills  can  be  reduced  to 
7**5.  A  true  on  any  input  line  causes  a  true  output  in  an  OR  gate.  Similar 
thoughts  affect  the  multiple  input  AND  gate.  Any  input  being 
false  will  cause  a  false  output. 

Depending  on  how  many  states  cause  constant  outputs,  this  method  may 
use  less  core  than  the  previous  one.  However,  the  designer  must  deal  with  the 
state  recognition  and  mapping  equations.  These  logical/arithmetic  computations 
may  consume  more  time  and  core  than  the  simple  direct  mapping  arguments. 
Experience  has  shown,  however,  that  this  method  presents  important 
advantages  over  the  simple  table  driven  models.  It  is  possible  to  carry 
the  use  of  equations  even  further  as  the  next  method  will  demonstrate. 

TRUTH  TABLE/LOG ICAL  EQUATION  DRIVEN  MODELS 


Devices  of  lesser  complexity  than,  say,  a  CPU  are  described 
in  the  data  books  by  a  truth  table.  Since  logical  AND  and 
OR  functions  are  a  part  of  the  ANSI  standard  FORTRAN,  it  is  possible 
to  write  logical  expressions  to  represent  output  vs.  input.  These 
equations  take  the  form  AHC+(-A)BC*0  and  so  on;  where  the 
left  hand  side  is  input  and  the  right  output.  Each  input  value  is 
stored  in  its  binary  form  (3=011  for  Instance.)  A  logical  manipulation 
of  the  bits  representing  the  Inpul  values  can  give  the  output  values. 
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By  usLij  logical  >-qu.it Ians,  cut  jail  value.1;  can  be  derived  from  input  values 
such  that  the  output  values  are  those  indicated  by  the  devices'  spec l f ir at t "it 
shoot.  These  logical  i  reunion  t  s  ran  also  he  i  mpl  rwn  i  oil  using  Ah'i)/OK 
eight-state  mapping  tables,  hot  instance:  the.  4-10  decoder  to  be  described 
later  has  16  equations  each  of  which  access  tables  representing  a  four 
input  OK  gate  and  a  one.  input  inverter. 

Extensions  to  the  aforemenf toned  equations  will  have  to  be  created  if 
the  specification  sheet  only  specifies  certain  input  events.  Some  data 
sheets  do  not  specify  the  results  of  all  eight  sLates  on  input,  only 
the  results  of  true  and  false.  Others  specify  rising  and  falling  slopes. 

It  is  still  necessary  for  the  designer  to  account  for  all  eight  states 
when  creating  a  behavioral  model  since  SALOGS  could  place  these  states 
on  the  input  lines.  Some  designers  simply  make  the  outputs  all 
undefined  if  any  but  the  truth  table  values  appear  on  the  input.  This 
is  acceptable  as  long  as  the  overall  modeling  goal  is  reached.  The  desire 
here  is  usually  to  perform  logic  verification.  The  valid  inputs  (in  the  sense 
of  the  allowed  input  space)  could  be  expanded  to  cover  any  of  the  eight 
SALOGS  states. 

The  tradeoff  in  core  and  time  must  be  carefully  considered  here.  A 
large  program  can  take  up  as  much  core  as  a  sizable  array  and  run 
much  slower  than  a  simple  table  driven  model.  Care  should  be  taken  to 
simplify  as  far  as  possible  not  only  the  code  but  the  logical 
equations  as  well.  The  tables  which  represent  the  eight  state 
OR  and  AND  gates  can  be  considered  as  free  because  they  are  accessible 
by  more  than  one  model. 

The  last  method  is  used  to  model  complicated  VLSI  circuits. 
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KUNCT LONAIj  nKSCKn’T  ID-;  MODELS 


For  tin;  mo,', l  complex  uf  Jcvin's,  the  data  hooks  provide  a  functional 
description  ol  tin.’  chips'  operation.  A  FORTRAN  program  can  then  ae 
written  to  describe  this  functional  behavior.  Certain  results  will  be 
guaranteed  by  the  manufacturer.  These  will  predict  the  output  only 
for  certain  constrained  inputs.  Other  input  events  must  be  accounted 
for  by  the  model  designer.  That  person  must  decide  what  should  happen  when 
events  outside  the  manufacturers'  specification  occur. 


MODELING  FOR  TRUE  CIRCUIT  OPERATION  VS.  SIMULATION  RESULTS 


Primarily,  the  designer  is  interested  in  knowing  whether  an 
unspecified  event  has  occured.  This  is  opposed  to  being  concerned  with 
what  the  chip  will  actually  do  under  that  stimuli.  The  prefered  simulation 
result,  in  general,  is  an  undefined  output  given  unspecified  inputs. 

What  a  chip  will  do  outside  the  valid  event  space  depends  on 
several  factors.  Among  these  are:  chip  technology  (MOS,  TTL,  etc.), 
configuration,  and  a  statistical  model  which  represents  which  batch 
the  individual  chip  came  from.  By  and  large,  designers  desire  a  model 
that  works  the  same  way  all  the  time. 

A  device's  configuration  is  usually  proprietary  information.  Therefore, 
it  is  not  always  possible  to  know  how  the  chip  is  put  together  and  thus 
gain  an  idea  of  what  will  happen  given  all  inputs.  The  manufacturer 
only  guarantees  and  specifies  the  results  given  certain  inputs.  On  top  of 
this,  designers  do  not  always  want  what  could  be  a 

recognizable  output  to  result  from  an  input  which  should  not  occur.  They 
prefer  some  flagging  output  to  mark  the  unexpected  event.  This  is  valid 
when  simulating  for  logic  verification  and  proper  system  performance. 
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C0NCU1S  lOUS 


There  are  several  ways  t  >  model  a  chi]''.  Thin  discuss  Lou  has  covered  simpl  •• 
tabic  driven  Models,  table/equation  driven  nodels,  truth  table/logical 
equation  Models,  and  functional  operation  nodels.  A  technique  should  be 
chosen  based  on  what  information  is  available  on  the  device,  resource 
limitations,  and  the  detail  required. 

These  methods  were  used  in  this  investigation  to  derive  behavioral 
models  for  three  digital  subsystems.  A  combination  of  methods  was 
found  to  be  helpful  in  realizing  additional  savings  in  the  amount  of 
computer  resources  required  to  implement  a  particular  device's  model. 
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Cll  6.  A  FUNCTIONAL  LEVEL  MODELTNC  LIBRARY 


To  fulfill  flu-  Ue.-i  of  f  'mot  lon.-il  level  oleliog  advanced  by  tills 
thesis,  a  library  of  FORTRAN  models  was  c  red  Led .  A  4-16  decoder,  2048  X  8  RO.'l, 
and  a  256  X  8  RAM  were  modeled  and  made  to  Interface  to  SALOGS.  They  are 
supported  by  eight  state  models  of  an  inverLer  and  a  four  input  OR  gate. 

These  were  chosen  because  of  the  Immediate  needs  of  the  sponsors.  These 
needs  reflect  current  projects  which  they  have  undertaken.  A  balance  was 
struck  between  core  and  time  usage.  Each  model  reflects  trade-offs  in 
detail,  complexity,  and  resources  as  well  as  in  the  accounting  for  the 
results  of  input  events  not  mentioned  In  the  data  books.  All  of  the  models 
were  tested  by  writing  SALOGS  routines  which  would  exercise  them 
through  the  several  functional  operations  specified  by  the  manufacturer. 

The  tests  were  then  compared  with  the  expected  results.  In  all  cases,  the 
simulations  were  found  to  perforin  as  described  in  the  data  books. 

The  remainder  of  tills  chapter  will  be  concerned  with  the  three  models, 
including  their  construction,  operation,  and  use.  Reference  will 
be  made  to  their  block  diagrams,  flowcharts,  and  listings. 

THE  4-16  DECODER 


The  4-16  decoder  is 
longest  time  to  model, 
kinds  of  models  and  an 
to  be  reached. 


discussed  first  because  it  took  by  far  the 
Techniques  had  to  be  developed  to  create  various 
understanding  of  the  realities  of  chip  use  had 
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A  4-16  decoder  basically  performs  thLs  function:  Tlu*.  binary  value  on 
the  four  Input  linen  in  read  and  evaluated.  Depending  on  that  binary 
value,  one  of  the  sixteen  output  lines  is  set  low;  the  rest  are  set 
high.  For  instance,  0001  on  the  input  would  couse  output  line  1  to 
go  low  and  lines  0  and  2-15  to  go  high. 

As  a  first  step  in  modeling  this  device,  a  large  photograph  was  taken  of 
its  gate  level  diagram  found  in  the  data  book  [N 1 , 1— 56 J .  Names  were  then 
written  on  each  node.  A  SALOGS  gate  level  model  was  next  constructed  to  exactly 
represent  the  photograph.  This  model  was  then  tested  for  results,  outputs 
vs.  Inputs,  to  derive  the  eight  state  results  of  all  the  possible  input 
combinations. 

At  first  a  simple  table  driven  model  was  attempted.  Required 
for  this  was  an  input  array  8  X  8  X  8  X  8  and  an  output  array  8**4  X  16. 

It  was  subsequently  decided  that  this  was  a  bit  too  much  core  even  though 
the  simulation  would  execute  very  fast.  So  a  truth  table/logic  equation 
driven  model  was  tried  next. 

To  support  this  a  tahle/equation  driven  model  of  ?  four  input 
OR  gate  was  created  along  with  a  simple  table  driven  model  of  an  inverter. 

The  truth  table  of  the  decoder  [N 1 , 1—58]  was  then  implemented  by  a  series 
of  16  OR  gates.  These  gates  perform  as  would  the  gate  level  SALOGS  four 
input  OR  gate.  (SALOGS  models  a  four  input  OR  gate  using  three, 
two  input  OR  gates.)  The  equation  for  each  decoder  output  line  is: 

D+C+B+A  ;  D+C+B+(-A)  ;  D+C+(-B)+A  ;  ...  ;  (-D)+(-C)+(-B)+(-A) . 

Each  decoder  output  line  is  driven  by  its  own  OR  gate. 
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Tin-  following  SAI.UGS  code  will,  allow  tin:  user  to  access  t lit*  dcroder: 


OKDKCOt)  0  16  6  20  6  0 

oo  o;  n:>  m  o'.  06  oo  07  08  no  m  li  12  n  14  is  * 

A0  r,o  fo  no 

end  o'oirr.oi) 

Send  models 
INPUT  A0  BO  CO  1)0 

OUTPUT  00  01  02  03  04  05  06  07  08  09  10  1  1  1 2  1 3  1 4  1  5 
ORDECOD  00  01  02  03  04  05  06  07  08  09  10  1 L  1 2  1 3  14  1 5  * 

AO  BO  CO  DO 

END 

If  using  the  SISL  preprocessor,  the  user  would  specify: 

ORDECODE  00  01  02  03  04  05  06  07  08  09  10  11  12  13  14  15  ;  AO  BO  CO  DO 
and  leave  off  the  SALOGS  $MODELS  portion. 

Appendix  E  shows  Che  listing  of  the  decoder  modeling  software. 

Refer  to  the  Appendix  and  the  SISL  USERS  GUIDE  for  more  on 
specifying  models  to  the  preprocessor. 


THE  2K  X  8  ROM 


A  ROM  "Read  Only  Memory"  is  a  device  which  has  a  series  of  binary  words 
pre-loaded  into  its  memory.  On  demand,  it  will  place  the  addressed  word  on 
its  output  lines. 
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Hardest  to  simulate  wen*  tin*  unspecified  input  events.  A  functional  oper  a  Lon 


specification  [12,0-34]  provided  the  bus  In  for  the  final  creation.  Sundiu 
Lab.  :i  nl .  •  dee  i  sinus  b  •;.>.!  on  llndr  viewing  of  proprietary  informal  Lou  as  to 
how  the  device  should  react  if  unexpected  inputs  occured.  Appendix 
G  show:;  the  original  block  diagram  of  the  ROM,  the  implemented 
block  diagram,  and  the  operational  flowchart  of  the  model. 

Appendix  G  also  shows  the  listing  of  the  software. 

To  access  the  model  use  the  following  SALOGS  code: 

$M0DELS 

ROM 8  0  9  18  27  10  0 

READY  DATA 7  DATA 6  DATA 5  DATA4  DATA3  DATA2  DATAl  DATAO  * 


CLK  CE  CEINV  ALE  RDIMV  IOMINV  IORIMV  * 

ADDR10  ADDR9  AD DR 8  AD DR 7  ADDR6  ADDR5  ADDR4  ADDR3  * 

ADDR2  ADDR1  ADDRO 
END  ROM 8 
$END  MODELS 

INPUT  CLK  CE  CEINV  ALE  RDINV  IOMINV  IORINV  * 

ADDR10  ADDR9  AD DR 8  AD DR 7  ADDR6  ADDR5  ADDR4  ADDR3  * 

ADDR2  ADDR1  ADDRO 


OUTPUT  READY  DATA?  DATA6  DATA 5  DATA 4  DATA 3  DATA2  DATAl  DATAO 
ROM  8  * 

READY  DATA 7  DATA6  DATA5  DATA 4  DATA 3  DATA 2  DATAl  DATAO  * 

CLK  CE  CEINV  ALE  RDINV  IOMINV  IORINV  * 

ADDR10  ADDR9  AD DR 8  ADDR7  ADDR6  ADDR5  ADDR4  ADDR3  * 

ADDR2  ADDR1  ADDRO 
END 

If  SISL  Is  to  be  used  specify: 

R0M8  READY  DATA7  DATA 6  DATA 5  DATA4  DATA 3  DATA2  DATAl  DATAO  ;  * 

CLK  CE  CEINV  ALE  RDINV  IOMINV  IORINV  AD DR  10  ADDR9  ADDR8  AD DR 7  * 
ADDR6  ADDR5  ADDR4  ADDR3  AD 'DR  2  AD  DR  1  ADDRO 

and  leave  off  the  SALONS  $M0DELS  portion. 
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The  Mi  V  f  node]  i  •;  .1  FORTRA"  suhi  ■ .  1 1  Inc  ml  rroring  tin*  functional  specif  icat  ion.-; 
fou, it  lii  t  Ac  '.l.il  :  book.  It  I  i'»  _u  Into  account  j  >  t'  >  >,»  r  :  clary  inf  o  final  1  on 
wbi'b  ic..l  ii-  H  ■  I  Iri.'  'b'  .i.-.i'-  build  r  •  i  ,  :  ,  u  ;  !ituit  not  i  a- lit  I  •mod  ia 
its  .*; pec i  float  ion  siioets. 

Till!  2  ■>(.  X  8  RAM 


The  256  X  8  RAM  was  relatively  easy  to  create.  A  RAM  "Random  Access 
Memory"  is  very  much  like  a  ROM  except  that  it  can  write  as  we  1 1  as  read. 
Its  information  may  indeed  be  pre-loaded  but  that  information  is  subject 
to  change  while  the  system  is  running.  Unless  a  new  loading  process  takes 
place,  the  RAM  will  Loose  its  stored  data  while  the  ROM  will  not.  [11,45] 
Appendix  F  shows  the  original  version  of  the  RAM,  the 
implemented  version,  and  its  operational  flowchart. 

Appendix  F  also  gives  the  listing  of  the  RAM  model.  This  model  is  based 
on  that  of  the  ROM  with  the  added  writing  feature. 
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To  .ii-r,"  ';  the  U\M  M  .  the  f  >> l ! . •  ,/i  ;it;  SAl.oGS  code: 

SMOPELS 

o  s  !  i  >:>  ')  n 

i ,  ,  ■  •  \i  .i  . i . •  ;  ■  1  >a i a 1  ; 

A.IDH7  >  A’X >:.■.>  ,  A!)pi<3  * 

Ai)i)H?  .'.'i  .:! 
end  rams 
$knd  m odlls 

INPUT  RESET  WR1NV  GRIMY  ALE  Hi:  1  •;'r  MMJN’V  * 

ap;>r.7  adieu*  apdra  addr3  * 

ad  dr  2  ad:)::)  ad.ero 

OUTPUT  DATA 7  DATA 6  DATA 5  DAT.v't  DATA 3  DATA 7  DATAl  DATAO 
RAM  8  * 

DATA 7  DATA6  DATA 5  DATA A  DATA 3  DATA 2  DATAl  DATAO  * 

RESET  WRINV  C ■: IN'V  MS.  KD[:;v  IOMINV  * 

AD DR 7  A DDR 6  AD DR A  AD DR  A  ADDR3  * 

ADDR2  AD DR  1  ADDRO 

END 

If  SISL  processing  is  to  be  done  use: 

RAM8  DATA 7  DATA 6  DATA 5  DATA4  DATA3  DATA 2  DATAl  DATAO  ;  * 

RESET  WRINV  CEIXV  ALS  RDIN'V  IOMINV  ADDR  7  AD  DR  6  ADDR5  ADDR4  * 

ADDR3  AD DR 2  ADDRl  ADDRO 

and  leave  off  the  SALOGS  $MODELS  portion. 

This  model  also  uses  the  functional  specification  modeling  technique.  For 

further  detail  on  SALOGS  and  its  use  of  models,  refer  to  the  Apj endix  and 

the  SALOGS  USERS  GUIDE.  See  Appendix  H  for  a  listing  of  the  commands  needed 

to  bring  the  various  SISL  and  SALOGS  software  on  line.  The  package  is 

supported  to  run  on  the  DEC  SYSTEM  10  using  the  TOPS-1 0/603A9G . 04 


operating  system 


CM  7.  A  UIAMKW  OK  I!,'!)  IV!  DUAL  I'UNOT 1 ONAI.  MuDU/INC  l,AN(;iiAf;i:S 


B  •r--’r«*  Uiv;.- 1  ih  i  ■!  -  *  'i.«  pr  •  j  >  r  * "  •  <  •  n*  ,S  JSI,,  it'  wool *5  J»<>  i  ;i  strucf  !.■■■ 

review  soai!  of  the  language:;  •-.! i  t  h  luvc  already  been  create*!  for  CAD .  A  stu< 
of  languages  was  under Laken  to  help  decide  on  the  detail  required,  how  a 
language  structure  should  be  defined,  and  to  discover  a  standard  upon 
which  a  user  interface  could  be  based.  The  convenience  of  the  user  Is 
very  important  as  is  the  following  of  commonly  accepted  standards  of 
circuit  modeling.  The  chosen  language  must  be  expandable  so  that  is  can 
remain  current  with  modern  technology. 

There  are  many  levels  at  which  one  maj’  represent  a  digital  system. 
Vertically,  the  following  levels  in  order  of  detail  may  be  chosen: 

-  electron  or  physics  level 

-  discrete  device 

-  circuit 

-  gate 

-  chip 

-  functional 
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S1SI.  models  the  structure  of  systems  .it  the  functional  level  ami  SA1/K1S 
simulates  systems  at  the  gate  level.  Together,  tliey  let  the  designer 
nod.  '■  at  Liie  .s  i'1,  eliip,  am!  I  luetioual  levels  all  at  the  same  time. 

Horizontal ly ,  one  may  split  the  system  into  many  or  few  modules  or  subys terns. 
The  behavior  o£  the  total  system  may  he  studied  in  more  or 
less  detail  by  observing  the  simulation  states  which  appear  on  the  lines 
interconnecting  the  subsystems. 

Many  languages  have  been  created  by  others  working  In  the  field. 

These  permit  the  description  of  exercising  of  digital  hardware  at  one 
or  more  of  the  horizontal  and/or  vertical  levels. 

ISP  (Instruction  Set  Processor)  (S3, 39] 

ISP  was  developed  to  describe  a  computers'  programming  and  register  transfe 
levels.  Thus,  it  can  be  used  to  study  the  behavior  of  a  digital  processor.  It 
describes  computers  by  using  various  fixed  formats.  Permitted  are 
declarations  and  actions  affecting  memory,  processor  state,  primary  memory, 
console  state,  I/O  state,  data  types,  data  operations,  and  instruction 
formats.  Overall,  it  allows  one  to  model  computers  at  a  very  high  level  but 
does  not  describe  the  inner  workings  of  the  hardware  beyond  register  transfer 
operations . 
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AUPL  (A  Hardware  l’rogr .1:11:11 1  ii;-  l.ango  ige )  (116,28] 

A.A'i,  L’i  ■  coiuViit  ions  <>i  A. 'I,  (A  i'i  o;,  I  uy.  1  1 1  igu.i  go  )  [ 

to  describe  il  i.  >  i  r  1 1  hardware.  Its  utility  comes  froi.i  tin*  partitioning  of 
a  .system  into  a  control  section  and  a  data  register/ logic  section.  The 
control  circuit  c-nisos  register  transfers  to  take  place  In  the  data 
section  by  putting  signals  on  its  control  lines.  Branching  information 
from  the  data  section  influences  the  sequence  of  tin*,  control  signals. 

This  is  a  very  low  level,  register  transfer  language.  It  does  not 
precisely  describe  the  structure  of  a  digital  system  but  simulates 
its  output  based  on  input.  Its  simulation  is  based  on  the  moving  of  data 
from  place  to  place  and  may  be  said  to  work  at  the  information  level. 

PMS  (Processors,  Memory,  and  Switches)  [S4,42] 

PMS  will  allow  the  description  of  computer  systems  in  terms  of  the 
physical  interconnection  of  a  small  number  of  elementary  components.  One 
of  Its  main  alms  is  to  create  a  standard  whereby  designers  may  discuss 
their  simulations.  It  can  be  used  to  focus  on  certain  structures  or 
register  transfer  and  switching  circuits. 

The  basic  component  types  are  memory,  links,  controls,  switches, 
transducers,  data  operations,  and  processors.  These  seven  components 
can  be  connected  to  create  a  eighth  type  called  a  stored  program  computer 

Many  of  the  basic  component  types  here  are  required  in  the  description 
of  digital  systems  in  general.  It  would  be  possible  to  describe  the 
behavior  of  a  specific  chip  using  this  language.  A  problem  is  t ha t  a 
simulation  project  would  be  made  much  easier  if  specific  elements 
were  available  which  described  the  behavior  of  given  devices  which 
can  be  purchased  oft  the  shelf. 
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FST  (1'iMntLonal  Si  s.ail.al  it  and  Trans  La  t  i>r )  [37,46] 


FST 

gives  a  lies 

igller  the 

.’Ml  i  f  v  to 

:p'  -e  1  i  V  1  eg.  1 

.•  1  s 

e,,",. 

■ii' 

■s  of 

ope  r.i  1  i 

ions  without 

having  I  1 

>  e \p 1  to  1 1 1  y 

specify  tin 

■  coul 

;•<)  I 

L.e 

■  ic.  Models 

are  do: 

;er thed  in  s 

equeat i al 

and  concur  re 

sit  blocks. 

Any  c 

out  r 

ol 

logic  l* 

implicit  in  tlu’  description  of  a  block  and  is  produced  by  FST  itself. 

This  language  presents  ideas  which  are  very  near  to  what  is  desired 
in  the  new  language.  It  handles  structure  and  operations  separately 
and  can  be  used  at  a  variety  of  modeling  levels.  (A  block  could  be  an  AND 
gate  or  a  CPU  for  instance.) 

LALSD  (Language  for  Automated  Logic  and  System  Design)  [S7,47] 


LALSD  uses  a  multi-level  modeling  approach  which  allows  simulation 
at  any  level  of  detail.  Designs  are  seen  to  have  two  parts:  structure  and 
control.  It  is  very  much  like  AHPL  in  that  the  control  section,  describing 
system  behavior,  sends  signals  to  the  structure  part  to  initiate  operations. 

This  language  also  allows  the  partitioning  of  a  system  into  sub-blocks 
which  can  be  easily  integrated.  It  has  facilities  for  linking  subroutines 
to  its  base  software.  Control  signals  were  separated  from  the  structure 
for  the  following  reasons: 

-  If  a  person  is  only  interested  in  the  behavior  of  a  system,  it 
is  not  necessary  to  study  the  structure. 

-  The  control  part  can  be  implemented  in  hardware,  firmware,  or 
software.  Thus,  there  is  a  flexibility  which  aids  economical  realization. 

-  Such  a  model  is  very  convenient  for  high-level  modeling  such  as 
looking  at  determinancy  and  deadlocks.  Exhaustive  simulation 

is  avoided. 

The  general  ideas  behind  the  language  are  very  much  In  keeping  with  the 
goals  attempted  by  this  investigation.  It  will  allow  working  at  arbitrary 
levels  and  intermixing  them  in  one  Simula! ion. 
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SOI,  (St  ructural  rtptton  I,in;',-i  [V2,l] 

SOi.  d  ■  r  i  be.  I  d.-iiil  tic  it;  tcuii.i.i  t  I  at.,  of  a  ■  ■  r  i  *  •  • .  <  f  digital 
blocks,  These  blocks  nay  be  ol.  aay  modeling  Level,  It  wi  1  1  also  specify 
the  Interfaces  between  two  or  .ttore  subsystems.  Contained  in  its  syntax  is 
the  ability  to  describe  node  names,  block  antc-s.  Interconnections  between 
blocks,  numbers  of  I/O  lines,  and  other  specifications  used  to  fully 
define  the  construction  of  a  digital  system.  Tn  short,  one  could 
take  a  schematic  and  translate  its  stricture  to  SDb. 

Because,  of  its  syntax  rules,  which  allow  the  easy  specification  of 
a  system  structure,  this  language  could  fulfill  the  requirement  for 
specifying  the  Interconnection  of  elements  which  are  at  first  undefined  in 
their  behavior,  SDL  does  not  intermix  behavior  modeling  with  structural 
modeling , 

IN  SUMMARY 


From  the  above  discussion,  the  reader  will  note  that  several  of 
the  above  languages  meet  many  of  the  goals  as  outlined  in  the  Introduction, 
It  remains  to  combine  the  best  features  of  each  to  solve  the  particular 
problems  at  hand.  Tills  combination  is  found  In  SISL  and  Its  interface  to 
SALOGS . 
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S1SI..  A  view  of  1 1  ,i  inner  del  ills  will  he  given  along  witli  the  basic 
philosophy  behind  the  language •  This  will  demount rate,  its  coup  1  otoness 
as  well  as  its  usef  ul  In  ess  to  CAD  activities. 

There  are  several  requirement;-  which  have  been  noted  by  those  who  write 
description  languages.  These  are  necessary  for  the  clear  and  complete 
specification  of  a  digital  system.  {f)5,l] 

1.  ability  to  name  and  describe  blocks  which 
correspond  one-to-one  with  those  of  the  system 
be'ng  designed 

2.  separation  of  process  and  control 

3.  support  for  several  modeling  levels 

4.  separation  of  the  various  phases  of  simulation  and  testing 

5.  allowance  of  concurrent  activities  at  the  several  modeling  levels 

6.  specification  of  s /nchronous  and  asynchronous  activities 

7.  description  of  data  routing  between  elements 
To  these  may  be  added: 

8.  support  of  the  user  in  his  attempts  to  describe  a  system 

9.  easy  interfacing  to  other  design  packages 

10.  following  of  standards  which  are  generally  accepted  in  the 
design  community 
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Tlii-  choice  nil'll-  lor  a  langur;,-  to  support  the  Intermix! . ii{»  of  fimettonul 
and  gate  inode  Mm;  levels  was  based  oil  the  above  criteria.  SI)I.  was  chosen 
fiii  la  bis  .-  ; .  n ;  . ;  of  sins  laril  ogi-  I  i  a;;  an. I  S'l'IGS  n’.r:  rhoa-a  for 
process  control.  (See  Appendix  I)  tor  a  description  of  SALOGS.)  The  review 
of  Lite  other  languages  was  used  to  create  SLSL  which  coni)  lues  syntax 
features  of  Shi.  and  SALOGS.  It  extends  the  modeling 
capabilities  of  SALOGS  by  making  it  much  easier  to  use  beyond 
tbe  gate  level. 

The  syntax  of  register  transfer  level,  programming  level,  and  information 
level  modeling  did  not  appear  to  be  conducive  to  the  intermixing  of 
widely  separate  design  levels.  However,  the  general  ideas  presented  by 
the  other  languages  were  valuable  in  the  effort  to  derive  the 
new  language,  SISL. 

The  details  availsable  on  SDL  were  sufficient  for  an  in-depth  study  of 
that  language.  Also,  its  syntax  is  very  close  conceptually  to  such 
languages  as  PCAP  (Princeton  Circuit  Analysis  Program)  [58,1]  which 
is  a  discrete  component  level  circuit  simulation  package.  Many 
practicing  engineers  began  by  using  similar  design  aids.  An  intuitive 
feel  for  SDL's  use  can  be  easily  developed  since  it  is  "natural"  to  a 
human  user.  SDL's  syntax  works  very  hard  for  the  designer. 

Thus,  a  subset  of  SDL  was  chosen  to  begin  the  construction  of  SISL's 
syntax.  It  was  modified  slightly  to  conform  more  closely  to  that  of  SALOGS 
and  to  cover  some  areas  that  might  help  the  user  make  fewer  errors 
when  describing  a  system.  (More  on  this  later.) 


sisi,  details 


S  1  S  I,  i  !  ;  U  !|  r  i  n  :'l  !  I  !  V  In  »1  ■  •  r  I  ll.  ■  .  i  ;>i  t  )  i  i  l  n-;  i  ‘It  “I  i  1  SAL' '  'G:  I  .  ' 

It  lets  oiii!  dose  r  *.!>•■•  tin.1  struct  ur>-  of  arbitrary  (fund  iuiial)  level  digital 
systems  and  their  interface  to  the  gate  level  portion  of  those  systems. 

SISL  simply  adds  to  SALOGS  tlie  ability  to  easily  describe  structures  of 
a  functional  level  in  addition  to  its  gate  level  without  haring  to  do 
FORTRAN  coding  or  to  become  involved  with  the  details  of  SALOGS' 

$MODELS  section.  (See  the  SALOGS  USERS  GUIDE.) 

The  SAL0GS/S1SL  system  separates  process  and  control.  The  process  is 
the  behavioral  model  of  the  functional  element  written  in  FORTRAN.  Control 
resides  in  the  structure  of  the  digital  system.  A  behavioral  model  may  be 
changed  at  will  (as  long  as  the  number  of  1/0  lines  remains  the  same)  withou 
the  need  to  modify  the  system  structure. 


(*)  For  further  detail  refer  to  the  SISI.  USERS  GUIDE. 
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SISL  SYNTAX 


Appendix  R  shows  the  syntax  of  SISL.  There  are  two  d  i  f  f  erenros 
between  it  and  that  of  SALOGS. 

-  A  separates  the  list  of  output  nodes  and  input  nodes.  This  is 

to  force  the  user  to  carefully  consider  line  assignments.  When 
one  may  specify  up  to  AO  nodes  per  element,  this  becomes  necessary 
Also,  it  provides  an  aid  to  the  user  proofing  of  the  structural 
description. 

-  A  as  the  first  character  rather  than  only  in  column  i>  1 
flags  a  comment  line.  This  is  a  user  convenience  and  allows 
creation  of  banners  without  the  need  for  an  extraneously  filled 
column. 

The  syntax  rules  are  not  as  extensive  as  that  for  SDL,  the  model  for 
SISL,  since  only  the  interconnection  of  pre-defined  elements  Is  considered 
However,  SISL  is  complete  and  will  allow  the  description  of  system 
structures  where  the  elements  contain  up  to  AO  1/0  lines  each.  This 
limit  had  to  be  set  due  to  SALOGS'  internal  restrictions.  SISL  is 
designed  to  interface  easily  with  SALOGS. 
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which  is  mi-. ml  for  relttse  to  those  who  have  m»  need  to  understand  the 

inner  work ings  of  the  software.  Basically,  a  philosophy  of  error 

check!  ng  should,  Include  the  detection  of  problems  at  the  earliest 

possible  point  in  the  program.  Krror.s  should  not  be  allowed  to  propagate 

beyond  their  point  of  earliest  detectability.  Too, 

The  user  must  be  able  to  determain  whether  failure  of  an 
attempted  oper.it  Ion  was  due  to  improper  control  signals 
or  system  malfunction  [P3,13]. 

If  "...improper  control  signals..."  is  replaced  by  "...improper  user 
input  data...",  an  idea  is  obtained  as  to  hot;  to  approach  the  delivery  of 
error  messages. 

While  SlSb  will  not  catch  all  conceivable  user  errors,  it  will 
note  errors  duo  to  syntax  violations  and  Inconsistencies.  These 
include  a  node  being  used  for  input  but  not  for  output  and  an 


incorrect  number  o 


1 /t)  nodes  for  an  element 
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lot  to  '•>'!  1  n  ■  a  sli'iu  t  i!!'i'  it  tiif  fnn.tioiiil  1.  ,il.  ( See  Append i<  A  fur  aa 

eXU-'ip  1  •  ■  •  ) 

No  node  111:110  i'liii.’ors  toil;'.  :iro  mail  1  *  al  thou;',:!  a  I  SI,  will  cheek  tlio 
correspondin'*  of  niii’i'a  fi  of  1/0  linns  and  t’10  nnmi  ng  conventi  nus. 

It  will  also  ensure  too:  oach  node  is  used  at  least  one**  for  input  and 
for  output  •  During  t'ae  parsing  of  the  several  syntax  diagrams,  S1SI,  will 
check  the  integrity  of  each.  Any  error  will  result  in  a  message  and  an 
immediate  controlled  termination.  The  syntax  diagramming,  which  guides  the 
parsing  of  user  input,  is  based  on  that  for  the  computer  language, 

PASCAL  [ J 2 ,  1  ] .  The  procedure  is  the  author's  original  design  Each  line  of 
input  data  is  dealt  with  as  a  single  entity.  It  is  not  necessary  for  SISL 
to  know  what  went  before  or  what  cor.es  later.  A  lines' 
syntax  is  translated  and  then  spooled  to  a  scratch  file  which 
eventually  becomes  the  $MODELS  heading  for  the  S A LOGS  gate  level  portion 
of  the  overall  system  description. 

Node  nmes  are  retained  as  is  so  that  throughout  a  complete 
simulation,  the  designer  will  not  be  troubled  with  several  words 
which  stand  for  the  sane  thing.  The  intent  has  been  to  case  the 
burden  placed  on  the  user  during  the  design  process. 
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of  S 1  SI.,  a  1  uuc S  loiinl  1  ■  .  -  i  ,»ropio>e»*:,:s.>r  to  tin-  gale  level  SA1.O0S  CA,')  packag 
<'iini  a  library  of  three  hcii  ivfur  il  models.  Tht*  slat**  of  the  art  ha.*;  bo  a  ad/*. 
b>  > nnse  tin*  sponsors  wi  ]  I  now  be  able  to  support  projects  previously  denied 
due  to  the'  D’-'C-'-K  model l up,  limitations.  An  easy  in i x  of  functional,  and 
gate  level  modeling  has  hen  achieved.  A  designer  may  directly  intermix 
the  two  levels  of  modeling  while  saving  main  memory  and  time.  The  assumption 
here  is  that  a  behavioral  model  of  a  system  element  will  perform  faster 
and  in  less  main  memory  than  its  gate  level  counterpart.  It  will 
deliver  less  detail,  but  the  extra  detail  is  not  desired  by  most  designers 
modeling  at  levels  beyond  the  gate  level. 

The  group  of  possible  users  include  all  of  the  institutions  presently 
making  use  of  SALOGS.  These  include  several  universities  and  industrial 
concerns  as  well  as  the  two  sponsors. 

SISL  is  presently  running  on  the  AVIONICS  LAHS  DEC  SYSTEM  10  and 
the  SANDIA  LADS  DEC  SYSTEM  20.  It  has  proven  itself  a  great  aid  in  the 
modeling  of  digital  systems.  Continuing  support  will  be  carried  out  by  the 
author  (see  VITA  for  address)  through  SANDIA  LAHS. 
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Presently,  only  the  following  are  In  the  behavioral  library: 
a  four  input  OR  gate,  4-16  decoder,  2K  X  8  ROM ,  and  a 
256  X  8  RAM.  An  ALU  would  he  encouraged  by  the  sponsors  as 
would  a  CPU.  An  extensive  timing  buss  would  also  be  valuable. 

Anyone  wishing  to  use  or  extend  the  features  of  SISL  or  its  behavioral 
library  should  feel  free  to  contact  the  author  or  the  sponsors. 
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SIS),  Structural  Int  erf  ace  l  .>  t  :n*  SAL!  'GS  !  ige,  is  des  f  yn'il  as  a 

functional  level  pr<-pro.-e  ;so>-  t<>  SALOGS  (SAa  1  in  U>Ore  .Simulator)  which 
i  ;;  a  gale  level  digit  '.1  simulator.  SALOGS  i  I  os  dl;»i  1  al 
systems  using  AND,  OR,  and  f  SVLRT  pr  imi  t  i  ces,  These  primitives  or  gates 
perform  due  in;’  the  simulation  nlnn.M  the  :;a:.i<  as  Jo  their  MOS  technology 
counterparts.  Eight  signal  states  are  used  to  partition  voltage  levels. 

These  eight  states  include  the  logical  states.  Refer  to  Appendix  D  of 
of  this  guide  for  more  on  the  application  cf  and  the  terms  applied  in 
in  relation  to  SALOGS. 

The  purpose  of  SISL  is  to  allow  the  description  of  a  digital  system  in 
terras  of  high  level  devices  such  as  adders,  shift  registers,  etc.  rather 
than  in  gates  such  as  AND,  OR,  etc.  This  level  of  description  will  be 
refered  to  in  this  manual  as  macro  descriptions.  The  term  gate  level 
simulation  in  used  here  to  refer  to  digital  simulation  using  MOS 
technology  behavior  models  of  AND,  OR  and  INVERT  eight  state  primitives. 

The  several  algorithms  attendant  to  SISL  per fora  their  preprocessing 
by  implementing  a  digital  system  description  language  very  close  to  that 
of  SALOGS  itself.  Thus,  the  designer  will  find  the  use  of  this  new 
level  of  modeling  quite  easy  to  transition  to  if  lie  has  gained  a 
familiarity  with  the  SALOGS  design  aid. 

Not  only  can  the  designer  work  at  a  very  high  level  of  system  description 
but  lie  can  link  a  gate  level  SALOGS  model  to  n  SISL  macro  model  and  run 
the  entire  network  as  one  system.  Tills  qutde  assumes  the  users' 
knowledge  of  SALOGS.  Appendix  D  of  this  qutde  contains  a  copy  of  the  most 
recent  users  guide  to  that  package. 
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SI  SI,  is  tli  ;  t itfil  I  .  i  )  nit  :i  ■;  :  i  I  mu  r  (  i  .  vi.  i 1  1  I  pr  up  r  iir .  ■;  i  r  t  "i  t  ’  i  ■  ■ 
gal.1  level  S.V.O'S  uolu  1  i  ig  soUimiv.  It  will  /ire*  >t  C  uuct  i  onal  level 
(k  ‘-c  rijit  or  information  and  return  l  ho  SALOGS  ;>■■  r.iniel  it;  requ  i  red  t «•* 
create  a  single  entity  f rum  Cue  functional  and  gate  level  portions  of 
a  digital  systems'  model. 

Fig  UG-1  shows  the  cun  time  data  and  control  flow  for  SAhOCS. 
Obviously,  this  design  software,  rune,  as  a  series  of  batch  programs 
interfaced  through  a  number  of  disk  files.  Fig  l'G-2  shows  how  SISL 
is  an  added  program  (preprocessor)  to  the  S A LOGS  series.  The  user 
creates  two  model  files.  One  nolds  the  SIS’L  macro  model  portion  of  a 
digital  system  and  the  other  holds  the  gate  level  portion.  These  two 
files  are  manipulated  by  SISL  to  produce  a  total  network  description  to 
be  processed  by  SALOGS.  SISL  does  not  produce  gate  level  models  for  the 
large  scale  devices.  Rather,  it  creates  linkages  to  FORTRAN  IV  behavior 
models.  These  behavior  models  (called  functional  models  in  the 
SALOGS  literature)  determine  how  the  device  operates  and  the  technology 
involved.  They  are  not  required  by  SISL  itself. 
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S  1  t>i*.  1  I  I  in": 

Djilh1'  1  llie-i  .11.-  rout  I'ol  flow, 
t 

i ■  !■!'*•. •'.*  ;•  i.-vi  •<•  r i ,it  top.  .-km-.  on  tin-  salogs 

f  i  ..  '  1  1  1  :  cal  mo,!.-  I  •;  to  i  !i  {  ,  1  i  ! .  • .  Tit  in  i  i  !  .•  in 

sent  on  to  SAl.OGSj* 

SISL.bAj-  Tlu-  ,c  r  i  i>t  Lon  of  the  functional  level  digit  .tl  system. 

SISE.KAU’  A  lint,  of  device  names  and  their  individual  number  of 
I/U  li-v.e:  and  internal  subroutine  names. 

SI.SL.0iVf-  All  messages  generated  by  SIS!,  during  its  last  run. 


USER  INITIATION 


SETUP.DAT - > 

S1SL.  NAM - > 

SISL.DAT - > 


1  1 

1  1 

1  1 

1  1 

1  1 

1 

1 

j 

_ __>>  QTQT  fUTT 

1 

1 

1 

SISL 

1 

1 

1 

1 

J  !j  i  U  /  •  U/Y  1. 

SETUP. HAT  - > 


SALOGS 


FIG  UG-2 


SIS1.  RUN  TIME  SYSTEM 
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sisi.  sygiu 


. '  I  i  !  ■  ;  i  .  .  •  >!.  •  r  l;H  io:i  !  inguag  •  ■  .  i  !  I  r  t*»  (.  ■  i  it 

d>;v- ■ !  '.•••  G  by  L'..’!.  V. » ;  i  Clovnipiil  tor  It  i ::  SDL  or  Structural 
Description  La... vi  :,;a  [V2,  1  }  .  for  all.  the  seemi  ng  c.mpl  ox  tty, 
the  source;  cod-  lor  S1SL  is  only  1100  linos  of  FORTRAN  IV.  Appendix  C 
of  this  outdo  contains  tho  li  st  i  ng  of  t  iie  sofLware.  Appendix  B  of  tliis  gu 
gives  the  set  of  syntax  diagrams  which  completely  define  this  language. 
One  need  only  study  those  constructs  to  understand  the  syntax. 

AN  EXAMPLE 


To  demonstrate  the  use  of  S1SL,  a  complete  run  vd.ll  now  be  presented. 
Fig  UG-3  is  an  example  of  the  block,  diagram  of  a  digital  system.  In  the 
next  section  examples  will  be  given  of  each  file  required  to  program  it. 

There  are  several  steps  required  to  build  a  functional/gate  level 
model.  These  steps  are: 

1.  obtain  the  gate  diagram  for  the  gate  model 

2.  code  this  model  in  the  BALOGS  gate  level  language 

3.  test  for  compile  and  execution  errors  of  this  model 

4.  decide  on  the  functional  level  additions  to  the  gate  level  model 

5.  write  the  STS!,  functional  level  portion  of  the  overall  model 

6.  test  this  portion  for  compile  errors 

7.  run  a  test  on  the  total  f  unct  tone.l/gate  model 

8.  repeat  steps  1-7  until  results  are  satisfactory 

The  gate  level  portion  of  this  system  consists  only  of  an  AND  gate. 
Since  the  designer  is  assumed  to  already  have  some  expertise  with 
SALOGS,  we  will  only  discuss  the  SISL  requirements  of  the  system. 
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Tin  ••••  i  i  li-'i  r.-.itt 1  ’.I  .1  ■  !  to  t  <•••  » i.NL  pi't'jir  Tb<";.* 

)!!.•:  ]  >  ■  1  •  v  i  >  •  ■  I'.ii-  i  n  i  u  1 1 ,  i  I  .hi  r  1  •  ••  1 1 1  i  t  i  by  Si. 'i.  at  1  mi  t  i  i-:  -  * .  Ko  I  looing  is 
a  li  u  ill.  those  ill*  ,  Rescript  inns  of  t  h-  i'  required  format,  and  a 
sample  of  each.  Together,  these  file  demons !  r  1 1 e  the  prugran.nsi  up,  of  tin* 
block  oia;;i'  a  t',i.  1 1  in  Fit;  HG--3- 

SETUP.  DAT  The  SALOGS  gate  level  portion  of  the  inteude  !  d  i g  I  t  a  1 

system;  SIS!,  adds  to  this  file  the  linkages  to  anv 
required  behavior  -.no dels.  Refer  to  SALOGS  USERS 
GUIDE  for  the  details  of  gate  level  modeling.  SISL 
assumes  that  this  file  originally  contains  no  $MO))CLS 
sect  ion. 


Original  version  (created  by  user); 

INPUT  ABC 
OUTPUT  K 
AN!)  K  H  I  .J 
CIRCUIT  H  I  J  A  n  C 
END 


Final  version  (created  by  SISL): 


$ MODELS 

COUNTUD  033 

r  L  I)  A  B  C 
END  COUNTED 

BTOG  033 

11  1  d  K  E  D 
END  BTOG 

CIRCUIT  233 
II  1  J 

COUNTED  E  K  1)  A  B  C 
BTOG  11  1.1  EL  D 
END  ClthTIf 

$i;;:d  models 

IN  ED  I'  a  b  r. 

our  HIT  K 

AND  K.  1!  1  J 

CIRCUIT  U  1  .1  A  B  C 

END 


6  2  0 

6  1  0 

6  0  0 
A  B 


C 
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S!.il..t)AT  Htr*  t! 

•  ■  .  ■  1  p  I.  i  on  o 

1  the 

:  . )  (jo  r  l  I  on  “1  t  • 

le  dig 

1  l  a  1 

i  .  b 

•  '  i  ■  .*  i  i  ■  -  ’  i  i  .  .  i  ;  i 

i  Lh  - 

■ ,  • 1  r Iv 

is  :  ■ 

a :  imi'd  all 

i  l  i  i  it 

s  .'!  L  [  t'.iulmt:  T/o 

li  no.; 

in  this 

£  a s :  i  i  ■  >  >  i : 


DEVIL:.  : 

\  1  i'(  (  1  Y\l  ■  j .  )  l  > '.  1  L  I  I  (!)]’; 

\  t  a ; )  ;  (  S P AC E ) 1 X 1 ,  f S  T  where 

OCTLIS'l 

i s  the  1 i : 

it  of  UOllcf 

a  fo ruling  the  output  from 

1  tlu- 

dev  i.eo 

and  INI.!  NT 

is  tlu*  1  i.: 

it  of  inputs  to  the  duvie 

t‘  - 

The  fir s L  non-coiiMieul  line;  of  this  file  is: 
CONNKCT(SPAC K)OUT I  fSTCSPAC’:) ;  (SPACB)  INLT ST  where 
OUTLI.ST  is  the  list  of  macro  model  outputs 
to  the  pate  model  and  INLIST  is  the  list  of  inputs 
coming  from  the  gate  model. 


* 

* 

* 

*  THE  SECOND  TEST  OF  TUP.  SISL/SAI.OCS  TRANSLATOR 

* 

* 

* 

CONNECT  Hid;  A  ?.  C 
Cor  NT  I'D  r  E  D  ;  A  B  C 
mod  Hid;  V  1;  D 

Con t  Inna t  i.ons  are  notr."  by  ustiv;  a  space  fol  1  owed  by  a  n*"  al  the.  end 

of  the  continued  line.  A  line  may  he  continued  from  any  point  where  a 

.space  occurs.  Comment  linos  are  noted  by  having  .1  as  the  first 

character  of  a  line.  An  example  of  a  cent  lnu.it  i  on  follows: 

CONNECT  H  Id;* 

A  R  C 


01) 


SIS 

J  #  ► 

•’AM 

A  )  !  s 

1  nl  all  t  In*  a  1 

h  i;*h 

1  .’V 

el  . 

dev  ice 

cert  a 

i  n 

paraa-.! 

■  t  nr.  i  •  i  a  •  t.i 

.■all 

Eve 

ry  1 

if  i'h  1. 

a-al  < 

b-viee 

u.-.aS  1 1 

-  by  .SlSL  .in.'!  h. 

i  v*  i 

C.Otii 

j  u 

I  lie 

beha.* 

ior'l 

1  5  1,1-  . 

:  y 

is  T  i  : L  i  •  1  in  lli  i  v.iy  : 

LJNi:  l —  Dev  •  ( c<»l  1-3),  l  ft  just  i  I  i  ■>  cole  an 

one 

LINK  2 —  number  output  nodes  required  (col  1-5) 
number  input  nodes  required  (col  6-10) 

SALOOS  functional  ’node!  number  (col  11-15). 
All  numbers  are  integer  and  right  justified. 

BTOG 

3  3  1 

COUI.’TUD 


SISL  OUTPUT  FILES 


SETUP. DAT  Tile  combination  of  SALOOS  gate,  functional,  and  logical 

models  created  by  SISL.  This  file  contains  the  total 
system  to  he  simulated  ami  is  passed  on  to  SALOGS. 

SIS!,. OUT  All  message*;;  generated  by  SISL  during  its  last  run.  Each 

message  is  of  the  format : 

SUBROUTINE  GENERATING  MESSAGE,  FORMAT  NUMBER,  and  MESSAGE 
Fig  UG-4  gives  an  example  of  this  file. 


■■  ■  >d r ri : r: :  '■  iLrurs  it  uni::; 

:j  i  (> 


FNUM?  HASH  i‘- 

1  5 

:»  1 1 


*  Tiir.  second  i'Ksr  or  r::i:  sise/sai.o:;.;  ’i kanslm.ik 


i  t  i  ri--  * 

in  lb—  connect  n  i  .i  ;  a  is  c 


CONi'CT  4  I  0-  — 

tot \t .  «  nodes  common  to  salons- 
ouirur  nodes  to  s  v.or.s-* 

INLET  NODES  LNOM  SA! .■  ''f'S  = 


***  OUTLIST  *** 

H 

I 

J 


***  INLIST  *** 

A 

IS 

C 

GKTMOD  2—  AM  BUILDING  THE  SALONS  FUNCTIONAL  MODELS 
linkin'  15—  cor,; run  f  e  n  ;  a  is  c. 

LINKIN’  15—  UTOC  II  I  J  ;  F  E  I) 

LINKIN’  15—  ENT) 


GKTMOD  1 1)92 — 

NODE  NAME  OUT FLAG 

A  1 

B  1 

C  1 

1)  1 

K  1 


IKK LAG 


HASH  it 
20 


LMI'UM!,  5 —  AM  BUILDING  THE  S ALDUS  LOGICAL  MODEL 
KNDMOI)  3 —  AM  REBUILDING  SETHI’.  DAT  FOR  SALOCS 

The  1  iinU.i'r  OI’TFl  AC,/ INFLAG  1ml  Lc  -.at  os  that  the  noth*  has  bean  usod  as 
an  out  i'M i  / i npu t  until?. 

FIG  UC— '♦  AM  LXAMULK  OK  SISL.OUT 
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SI  SI.  n  ,\:;v  !' ! 

S I  SI,  u  two  iii.-s,  H.'ii’I  an-l  Tl  'll’.!,  I  or  working  slor.  !}>■••  the:;.- 
fill";  'ir.  cm.  iIimI  .1  i.i  del  ili'f  eng  .my  ;,iv-.n  run. 

CAiiTiu';  o::  yiuhs 


Any  fi  U'  u?H‘d  for  output  by  SISL.  should  a Iwa y be 
backed  up  by  the  u:;ei'  prior  to  each  run  if  the  current  version  of 
that  file  is  desired  for  reteni ion.  This  is  particularly  true  of 
SKTUP.DAT  since  it  is  used  first  by  SISL  as  the  gate  level  portion  of 
the  digital  network  and  then  to  contain  the  total  system  description. 


APTENDiX  B 

SISL  SYNTAX  DIAGRAMS 


TAiii.t:  or  run  tents 


. . .  (,<, 

M f  i  *,  1 .  l ' :  \  A  *  ’  A  i  *  \  '  . . . *  .  . . . .  fill 

1)1  0  1  ]' . 

I  j)>;m  i  1 1’  1 1  ;■; . . . «... 

.  6  P, 

nodi:  ....  * . 

.  6 

IDENTIFIER  LIST . 

.  60 

NAME  OF  FUNCTIONAL  PRIMITIVE . 

> 

OUTPUT  OK  INPUT  LIST..., . 

NUL1 . 

NUMBER . 

. .  69 

ALPHANUMERIC . 

ANY  CHARACTER . 

NUMBER  RANGE . 

STRING . . . 

TEXT . 

MODEL  SPECIFICATION . 

CONNKflT ION  TO  CATK  M0T)1\! . 

.  71 

.  72 

SISL  PROGRAM . 

6  :> 


appendix  c 


si.se  i.Tsrr;c 


EACH  SUiiROUTIKE  IS  ERE  CKEOEii  BY  ITS  OWN  OP EkATING  FLOW  CHART. 
THE  FLOW  CHARTS  PORTRAY  THE  A  EGOR  ITEM  USED  TOR  EACH  ROUTINE. 


In  all  the  software,  liberal  use  is  made  of  certain  functions  which 
may  not  perform  the  same  way  on  all  computers: 

OPEN,  CLOSE  are  used  for  disk  file  bundling. 

•  AND.,  .OR.  are  used  on  integer  variables  for  data  packing,  and 
and  unpack l ng.  These  depend  on  a  shift  left  being 
caused  by  l.”! *2  and  a  shift  right  being  caused  by 
1=1/2  where  I  is  an  integer  variable. 

J="li  places  the  non-decimal  octal,  value  K  into  the 
integer  location  I. 


7  A 


CAM,1-:  (IK  < :( •>;; i' ■  \iS 


7  7 


HALT. 


00 


Of:.  . . . . . . . . . .  82 

Cur:; . . . . .  84 


],! 

HEX  I'll). 
I.MOL'LL. 
EN’DUOI). 
GETMOM. 
TEST ID. 
CONECT. 
CONCHK. 
IBKl’I’T. 
XDHASil. 
IDPUT.  . 
MODULO. 
ICHAR.  . 
IFIUD.  . 
LOOM..  . 
EX I  ST. . 
KEADPM. 


86 
89 
93 
9  Ci 
9S 
105 
107 
112 
114 
116 
118 
120 
172 
124 
126 
128 
130 


T> 


('.  lit:  ’  i !  ■ .  is  i 


m  i.  ■  c >.  •  ■  •, ; 


<:  si  ,i 


c:  !■»'  x  i  i .  \  i.m  ■  , : .  ... 

i: 

t:  vij  • '  '  :o  ’  :.;i  r;.i.  .  :  c  ;  i::;  i  ;t: 

C  hi:;'  •<>:  V.  i’.< :  :  ■  .  «>.  .  •.  i  .  k.\:  •  s.  i.  . 

c  co.,  i  s  ■■  i  ; o  i  - o. .  j  •  !  ,  i  1 1 •  oi-  rn::  i o r  \i. 


<j  s  : 

t  t ! i '  * 

ivy,  :c  : 

i‘. 

,  , . . . .  ! 

A  ii.ii  A 

c  \ 

• ;  : ; .  \ 

,  '.v  i  .  ..  i 

.  !>;■*  n\ ■  : 

C  Tn 

:  i;j 

•,'.•]  o  cm.  :• 

:•  i.  L’ Hi <; 

.  ,  '  ’  \  T 

[  • .  A  :  *.*  ' 

1 7 .  \ :  ’  K  TO 

C  S', 

,uk;:: 

■.VI- ■  V  V' 

’J  1 1 

VOVA’ 

1  ‘A  ’  ■  *  !’  ' 

c 

t;  this  l  ,  .s !  s: . sackin'  ivc.  r;:-; 

c  . .  tun  fj rn  rrokra::  t;  n:i;,  s Ai.< «; :*i  rnn  ti:jt  ,;v ; r;: 

c 

c  an  id  ( i i)i::c r if i is  a  no:;::  n.y 

c 

C  SYNTAX  OK  SIN!,  M;'SS,\H  S  —  > 

c  suhuouti ni:  na::,.,  format  kc.  inkr,  mcssags 
c 

C  Tin:  "?*'  IN  FN I'M?  IN  Tin:  "i"  IN  SirnKO'JTlNT  KNOT?  '..'Illdi  IS  THIS 
c  KKiiA vii'-i  nonin.  ;v rr.N  in  itctt.::  it  to  i  :.sNRTsi:  a 
C  Bllll-Wl  ORAL  ’’KOOK,  I  if,  VAR]  Oil,  SOB ROUT  LNi'S  FNTi?  UN  IQUiXY  IDENTIFY  A 
C  GIVKN  NNiiAVlO  NVs  ;;ioh:.\  to  S. Voles. 


7(> 


c 

c 


c 


f,  DATA  I).::  -Ck  I  ,’TlUN 

c 

i  r  " '  '  : . ;•.!  .  t 1 

C  l  r:A  AS  r  i  "  >;•'  \.;Ai:  r 
(1  1  0- ii,.' iN  A  SiAii'':'1  HAFvACT':.; 

C  N.  '!  UN  MAX.  '1  :  L  N.iii  OF  A  BLOCK  NAME 

C  MAXNM  1  MAXNAMI-l 

C  MANN  M2  MAXS/CIK* 

c  maxnmt  :  \-A  !i  x 

C  MAXNM';  MAXNAM+A 

C  IIAXULK  THE  MAX  1 1  UK !  NUMBER  OK  BEHAVIORAL  Ii  LOCKS 
C  LSTOUK  A  1. 1ST  OK  IF' ARAC  TEES  II:,  CD  Li'.’  SIS!., 

C  NAMES  A  LIST  OF  liLOCR  NAMES  AO)  Till'  CORRESPOND t SC 

C  NUMBER  OF  OUITDI1/ LNPU T  NODES  RED  MED  BY  EACH. 


C  NUMCIi.S  Tlii:  NUMBER  OF  CHAR. ACT  HS  I N  LSTGI1R 

C  MAX),  IN  T:E  LENGTH  OF  AN  INPUT  LINK 

C  KNDF1L  0,  NO  F.:,',)  01'  V II, K.  .  .  1 ,  END  OF  FILE.  REACIIF.ii  (INPUT) 
C  1DTS  17.  Till'.  SIZE  OF  1 DTABL 

c  ii) r AiiL  the  hash  table  for  ids 
C  MAXL1)  T lit:  ALLOWED  LENGTH  OF  AN’  IDENTIFIER 

C  MAX  ID  1  UAXID+1 

C  MAX  1 1)2  IlAXID+2 


C 

NO  ID 

0,  ID  I’O UNO 

;  I,  NO  ID 

FOUND 

c 

MAXCON 

TEE  MAXIM!"! 

MoMIU.R  OF 

NODES  WHICH  CAN  BF.  SHARED 

c 

BETWEEN  TEE 

FUNCTION  A 

.',)  GATE  LEVEL  PORTIONS 

c 

OF  THE  TOTA 

E  SYSTEM  111' 

,  v,R7.  i’T  ION. 

c 

LINE 

THE  CURUENi 

WORT! NO  IE 

.'FT  LINE 

c 

LINE] 

A  GENERAL  A 

UR AY  TO  HOE 

)  WORKING  INFORMATION 

c 

LIN END 

Tin:  END  OF 

1N1E  CURRENT 

WORKING  IN  PUT  LINE 

c 

IDPNTK 

Tin:  begin:; i 

NO  OF  THE  N 

IN','  IDENl’IEIER  IN  THE 

c 

CURRENT  WOE 

RING  INPUT 

LINE 

c 

LSTCOM 

THE  LIST  OE 

OUTPUT  ANN) 

INPUT  NODE  CONNECTIONS 

c 

c 

THE  SISL  10 
SALOGS  CAL 

UAVIOR.VL  '•:< >!>EI.  SHARES  WITH  THE 
:  :ooei. 

c 

NUMPIJT 

THE  NDM’iER 

0]'  NODE  NAM 

TO  pur  ON  A  SINGLE.  LINE 

c 

NUMCON 

j.n:  ciiKUE  :i 

Ni  Mil  U  OK 

NODES  IN  LSTi.ON 

c 

NUM1N 

TEE  NUMBER 

01  l.Nl’Ur  NO 

'EK  IN'  l.S  ICON  I 

c 

Nll.MO’Uf 

TEE  NUMBER 

or  oui'Fui' 

ONES  IN  l.S  : .  e:  | 

c 

c 

M0DCN1' 

THE  NUMBER 
BY  SISL. DA I 

OK  HEIIAVl  OR 

M,  MODELS  REFER ENG  El)  | 

C 


c 

c 

c 


c 


c 


COMMON  /MODE  LS  /  MODCN’T,  NUMPUT 

COMMON  /IDS/  11)1'. Mil,  ( 1  000,  10) ,  IDI’LAC  ,MAXI .1)  1  ,  MAX1D2  , 

1  IDISIZ 

COMMON /NAME/  NAMES  (Ml,  12)  ,  MAXN’AM , MAXNM  1  , MAXNM 2 , MAXNM3 , 

I  MAXNM A ,  MAXELL ,  l.s  C i : H i l (  70) ,  NUMCHR 

COMMON /SI  SI./  1, 1 NE  ( 80 ) ,  El  N’E  I  (SO)  ,  IP, LANK ,  1  ASTRA ,  MAXI,  1 N , 

1  El  NEED,  1  Dl’NTK ,  M  \XI  I) ,  NO  I D ,  KNNF LI, 

COMMON /NODES/  LSTCOM ( 1  00,  S)  ,  NUMOON ,  NDMOE !',  NUMI II.MAXCON, 
I  1  Co  I  ON 

7  B 


»n* 


( 


t 

*>% 

* 

4 

> 

;• 

* 

« 


c 

c 


DAT.  i 

NAME 

ip 

\  ,’0: 

>7  rip 

D*  1  :l 

/ ,  E 

1  NF./  Si)- 

-o/ 

,u 

NENi)/0/ 

i ;  ■  '• 

!  .1 1  ’. 

;  1  /  ; 

;  i  » 

/  >  1  '  ' 

i  •  i  : 

,  •'  >  '  '  I  !' 

, 

.  . 

D2/1  ■  ■  ■, 

S  10/ 

D.v;  A 

I.STC 

;,(/ 

hl.\ 

lilll. 

1UG, 

I'H). 

HIE,  1  ii 

,i 

.  j  (; 

li:u ,  i:;i 

HE), 

L  1  H  E , 

i  in.. 

iii;;. 

in.; 

Hit), 

INN, 

IN), 

INN,  Hi 

,  i 

NT 

1HU.1HV 

11 

2  HE-:, 

iHYj 

in / , 

I  Hi 

1112, 

11!  .3, 

i-14, 

Hi  s,  i  i 

i 

>17 

HIS,  1  ID 

1  HO , 

3  in  , 

1H,  , 

111. , 

111/ 

1H;, 

111:  . 

mo. 

mi ,  in 

,i 

i 

in  f ,  nr' 

UK, 

4  1 '  1> , 

111?, 

IN!-, 

lil* 

111-, 

in). 

1'7, 

nr ,  hi. 

i 

1  i7 

111$,  1 E 

in" , 

5  111!  , 

7*111 

/ 

DATA  I BLANK ,  lASTKA,  1001,0.'.’ , ' L\XL f  W ,  END!  11,,  MAXI D , MAXCON 
1  /111  ,  111*,  1 M ;  ,00,0.0,8,  100/ 


DATA  110DCNT ,  M  \XNAM,HAXHM  1  ,  MAXNM2 , MAXNM3 , MAXNM4  ,  MAXBLK , 
1  HUMOUR  /O, 8, 9, 10, 11, 12, 60, 70/ 


OPEN  ALL  FILES 
CALL  OPEN 


READ  IN  THE  LIST  OF  ALLOWED  BLOCK.  NAMES  AND  THEIR 
REQUIRED  NUMBER  OP  OUTPUT/ 1  Ni'UT  NODES  AND  THE  FNUM? 


CALL  READUM 


READ  THE  CONNECT  CARD.  THIS  SHOULD  BE  THE  FIRST 
SISL  COMMAND  CARD. 


CALL  CONECT 


TRANSLATE  THE  BEHAVIORAL  SYSTEM  DESCRIPTION  INTO 
SALOGS  FUNCTIONAL  AND  LOGICAL  MODEL  SYNTAX 


CALL  GETMOD 


PUT  THE  TRANSLATED  INFORMATION  FROM  S1SL.DAT  ON  TOP 
OF  SETUP. DAT 


APPEND  TO  "TEMP  1  THE  SALOGS  FUNCTIONAL  MODEL 
INTER! ACES. 


APPEND  TO  "TEMPI"  THE  SALOGS  LOGICAL  MODEL  "CIRCUIT" 
CALL  I, MODEL 

PUT  "TEMPI"  INTO  "SETUP. DAT"  AND  DELETE  "TEMPI" 

CALL  ENDMOD 

CLOSE  ALL  THE  FILES  AND  TERMINATE  EXECUTION. 


GAM.  CLOSE 
END 


7‘» 


i 


( 


c 

e 

c 

simuoijT  i  ::i:  i:.m .i1 

<: 

c  i ■  i : ■  i i '  ■'  n:’  i",  lo i  h 

c 

O' ■;  m  i  a./  i.i  ,  um.Usu) ,  i  las 

l  i . i r: i ;n ,  ini .. j  .;,m \.-u n.i  ■  c, i::u>:- 1 1. 
c 

warn-:  (2,  in) 
v,'!:  i  i:'.  ( 3 ,  lo) 

10  MAT  ('  li  ALT  10—  **  FATAL  ERROR  **  PROG 

IF  (LINEN!).  LE.O)  GO  To  20 
WRITE  (2, 1 5)  (LTNK(L),T  !1 , LINKND) 

WRITE  (5,15)  (LINE  (1  )  ,  T-l  ,  LIKEN!)) 

15  FORMAT  ('  HALT  15 — 

1  '  CURRENT  SJSL.UA7  COMMAND  LI NE=  ' 

20  CALL  CLOSE 

END 


81 


I  RA,  MAX’.  I  N, 


RAM  UAL  nil)  * 


,  80A1  ) 


siuiito j r  i oi'mm 


. .  I  \i,].  i,:  i  i;  i  ...i  iV  SI:.!,  A  i  K;  \  iJ.'ii.. 

cu»i-:N(u;i  IV  : .  j,  devi;::;  -'dnso'  ,  access  -'seoi  x'  .modi;-- 'ascii 
I  Dispose  ' ,  i’i  EV  :  sw.NA.i'  > 
opr.N'CJN’}  r  i  •>,:)!;vu:i.  'ds .v.'  ,acci;ss=  'seqin'  .modi:  ='ascii 
l  i) i spoon  'save' ..  ej  i,r:--'s:-,r:n\DAT'  ) 
on v (uk i  v-  ]  o, device  'p;:;c'  , A<n:t;ss-- ' i;i;q i  n'  ,mo!)i:--='asci  i 

1  DISPOSK-'S.vvK'  ,1-11. i:  ' S IS], .DAT'  ) 

oiv  n  (!.!■'!  i.v-  .access- 'sprout'  ,kodi>'ascu 

I  DISPOSE  'SAVE'  ,}•  I  l.iA' Ti':! I’2 '  ) 

OPEN  (UN  1T‘V  >  DEV !  C  ,-:■•■=  'llSKC'  .ACCESS  'SEQDUT'  ,M01)I>'ASCI  I 

l  disposer's, v/p'  , eieer'sise.out' ) 

0PK.\’(U.VIT‘-1 , DEV 10 i><  'DS RC '  , ACCESS^' SEQOUT '  .MODE -'ASCI I 

i  Dispose- 'save'  ,Fiu:-'rinii*i') 

REWIND  20 
REWIND  15 
REWIND  10 
REWIND  3 
REWIND  2 
REWIND  1 
RETURN’ 


AD-A1Q0  784  AIR  FORCE  INST  OF  TECH  WRI6HT-PATTERS0N  AFB  OH  SCHOO— ETC  F/8  9/2 

A  FUNCTIONAL  LEVEL  PREPROCESSOR  FOR  COMPUTER  AIDED  DIGITAL  DESI—ETCtU) 
DEC  80  P  S  RAETH 

UNCLASSIFIED  AFIT/GCS/EE/80D-12  NL 


c 

c 

c 

suiiKi'MJ i'i kk  next  id 

c 

ct  >'./j  i  .<r\.  [.(:■.■. ;i.-,  lo),  id:  <:  .in! ,  :\.uu2, 

l  i or six 

cum;io:;/s i  :;i  /  l r ni:(>;o ) , i  :;i:i  (  D) ,  i  liank ,  i as  iha , maxi, i f 
1  :a::l i: i, 

common/nodus/  lslv.u:; ( 1  uo , a ) , xu; icon , nunonr , nu. :n i,i van 
1  ICO LON 

c 

C  THIS  ROUTINE  GETS  THE  NEXT  11)  IN  AN  IDENTIFIER  LIST. 

C 

C 

C  CHECK  FOR  SPECIAL  CASES 
C 

NOID=0 

IF  (IDPNTR.GT. LINEND)  GO  TO  500 
IF  (LINI’(IDPNTR) .FQ. TASTRA)  CALL  LINEIN 
IF  (ENDFIL.EQ. 1.0)  GO  TO  550 
IF  (LINE (IDPNTR) .EQ. ICOLON)  GO  TO  475 
IF  (LINE(IDPNTR).EQ. IBLANK)  GO  TO  1500 
C 

C  PUT  THE  NEXT  ID  INTO  LINE  I 
C 

DO  10  1=1 , MAXID 

IF  (LINE(IDPNTR)  .  EQ.  T.BLANK)  GO  TO  100 
LINE1  (I)=LlNK(IOP.XVil) 

IDFNTR=IDPNTR+1 

IF  ( IDPfJTR. GT. LINEND)  GO  TO  100 
10  CONTINUE 
C 

C  PACK  BLANKS  AT  THE  END  OF  THE  ID 
C 

I=MAXID+1 

100  IF  (IDPNTR.GT. LINEND)  1=1+1 

IF  (LINE( JOPNTR) .NE. IBLANK)  GO  TO  600 
IF  (I. GT. FLUID)  GO  TO  200 
DO  150  K=I , MAXID 
LINE1 (K)=ISLAMK 
150  CONTINUE 
200  IDPNTR=II)PNTR+1 
DO  210  1=1 , MAXID 

IF  (LIUEl(I).EQ. IBLANK)  GO  TO  400 
ICHR=LINE1 (I) 

IF  ( ICHAR (ICHK) . GT. 36)  GO  TO  700 
210  CONTINUE 
4  0  D  ID  PLAC  «I DHA  S  H ( I DUMMY ) 

t\  15  RETURN 

C 

C  NO  ID  FOUND 

C 

500  NOID*l 
RETURN 


c 

C  ERROR  Mi::; SACKS 

c 

550  WRTTE  (2,551) 

v/sr-ri'.  ( ■> ,  s  5 1 ) 

.551  FORMAT  ('  NfTID  55!-—  FOF  0:1  II. I!  THY  1  NO  TO  (XT', 

1  '  CONTINUATION  CAW)') 

CALC  HALT 

600  WRITS  (2 ; 601 ) 

WRIT’S  (5,601) 

601  FORMAT  ('  NKXID  601—  I!)  TOO  LONG') 

CALL  HALT 

700  WRITS  (2,701)  (L TNK1 (I ) , 1=1 ,MAXTD) 

WRITK  (5,701)  (UNCI  (1)  ,1=1, MAXID) 

701  FORMAT  ('  NEXID  701—  10  CONTAINS  INVALID  CHARACTERS', 

1  '  (A-Z.0-9  ONLY)  ',1041) 

CALL  HALT 

1500  WRITE  (2,1501)  IDPNTR 
WRITK  (5,1501)  IDPNTR 

1501  FORMAT  ('  NF.XTI!)  1501—  A  BLANK  IS  THK  FIRST  CHARACTER 

1  '  OF  AN  IDENTIFIER',/,'  IDPNTR=  ',110) 

CALL  HALT 
END 
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(' 

r 

S"i  *'0"1  1  ,i-'  !,• 

c 

C  1  'I*-.  **€*•*  IT****  ''m'-M'KS  TH'  s/.f  or.s  l/T.TCMi  MO|iF|.  “flilCIIII  " 

C  A  *  i »  it  TO  TIT  Kiurric  .M,  >-l)r>Kt.  1. 1ST  MU  RESILING 

C  I  FJ'I-.  M“ 

C 

c  p-r  ;  i  ».•;  ii  r"i1"'  i.tm- 

r  t-’Is  i;,  T»h  .^t.t  ;tn".  <h  r'i-;  sMiifir.  i  dgical  ,!or>Ki  whici' 

C  I'1  6C u  I  t'l' f>  f-'t  OV £*'  At  L  '.Cl’O  fY. -5 . 

c 

r 

c  jjTi'Pf  THE  \Pp'U?FKTaTK  o  a  LOGS  t.OGJCM.  MOOET.  «»me  with  tts 

C  iv'- J  PAHft-  KTEHS. 

c 

c 

c  pi'l  <  r  T'M,  uM  \'>'UT/  T  \*M)  r  LIST 

S' 

c 

C  V'i’FHP  Tilt;  SlSL  SYSTE‘-'  HLOC K  t>A’!LS  WITH  THEIR  PARAMETERS 

C 

C 

C  -M*  Rrtt.OGS  L^GTC-J,  MODEL  K*T  FLAG. 

C 

c  r'pvjn  Tji**  AaT/'GS  t',iD  OF  F II  *'  C  T 1  '  T  *  l.  / 1 , 0  G I C  *  1 1  MOi)H,S  EMP  FL».G, 
C 


c 

c 

c 

subroutine  i. model 

c 

cmmon/ ;;oiJi:t.s/  mougnt.nu  v:*ut 

coMf ion/nodes /  ls icon (loo, 8), num com , mk shut , mum i n , maxcon , 

1  i COLON 

COMMON/SlSi,/  L1NK(80),LINU:1  (S0),IBLANR,IA.STRA,MAXLIN, 

1  LINEND,  I01’NTK,MAX1D,  NOTH,  ENDFIL 
C 

C  THIS  ROUT  INK  CREATES  THE  SALONS  LOGICAL  MOOLI,  "CIRCUIT” 

C  AND  APPENDS  IT  TO  THE  BEHAVIORAL  MODEL  LIST  NOW  RESIDING 
C  IN  FILE  "TEMPI" 

C 

c 

C  PRINT  THE  "CIRCUIT"  LINE 
C 

WRITE  (2,5) 

WRITE  (5,5) 

5  FORMAT ('  LMODEL  5~  AM  BUILDING  THE  SALOGS  LOGICAL  MODEL') 
WRITE  (1,10)  MO DC NT , NUMOU T , NLMJN , NUM CON 
10  FORMAT  ('CIRCUIT', 4(1X, 14),'  0  O') 

NUMPUT-80/ (MAXID+5 ) 

IF  (NUMPUT.LT. 1)  GO  TO  500 
M=0 

N=1-NUMPUT 

C 

C  PRINT  THE  OUTPUT/ INPUT  LIST 
C 

15  M-M+NUMPUT 
N=N  MNUMPUT 

IF  (M.GT.NUMCON)  M=NUMCON 
IF  (N.GT.M)  GO  TO  50 
IPLACE=0 
DO  20  J=N,M 

DO  18  K=1  ,MAXII) 

IPLACE=IPLACE+1 

LINE1(IPLACE)=LSTC0N(J,K) 

18  CONTINUE 

IPLACE=IPLACK+1 
LINE1 (I PLACE)=IBLANK 
20  CONTINUE 

IF  (NUMGOM.GT.M)  IPLACE=IPLACE+1 

IF  (NUMCON.GT.M)  LINE1 (1PLACE)=1ASTKA 

WHITE  (1,2  5)  (LINE1  (  I ) ,  1=1 ,  Il’LACE) 

25  FORMAT  (80A1) 

IF  (NUMCON.GT.M)  GO  TO  15 

50  IF  (MODCNT.LT. 1)  GO  TO  70 
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o  o  o 


C 

C  LIST  Til!'.  BEHAVIORAL  MODEL  LINKS 
C  TIIKSK  RESIDE  III  TElll^ 

C 

Cl  i)  'K  (ME  !  T 

nr.'  '(  ■■  mci:  ■  '.cgkss-'skqin'  .  -jont:  -'ascii', 

l  i)[srosK-'m:i..  ;  ,KU.i;-'iT;;U'2' ) 

RK.J  LCD  j 

55  UK  M)  (3,  25, !'... D--70)  LINE] 

WRITE  (1,25)  LTKH1 

GO  TO  55 

70  WRIT!-  (1,71) 

71  FORMAT  ('END  CIRCUIT' ,/,' $END  MODELS') 

RETURN 


ERROR  MESSAGES 

500  WRITE  (2,501) 

WRITE  (5,501) 

501  FORMAT  ('  LMODEL  501 —  UUMPUKl,  MDS'L’  BE>1',/, 

1  '  THIS  IS  CAUSED  BY  NODE  NAMES  BEING  TOO  BIG',/, 

2  '  DECREASE  THE  ALLOWED  NODE  NAME  LENGTH') 

CALL  HALT 

END 
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OOO  Ln  t— *  (jj  0000000  Ci  ooo 


SUBROUTINE  lONDMOn 

cw:;hon/sisi./  u ::e(so) , li  ni;i  («o) ,  [blank,  iam i:ka,m\xli.n, 

1  l.INEND,  lUPNfi,  MAXI  I) ,  KM  1 1) ,  1- N DEL L 

REMARK  SETUP.  DAT  TO  HAVE  AT  ITS  HEAD  THE.  NEW  MODE. UNO 
INFORMATION  CREATED  BY  SISL.EXE 


GET  "SETUP. DAT"  AND  APPEND  IT  TO  "TEMPI" 

WRITE  (2,3) 

WRITE  (5,3) 

FORMAT  ('  EHDKOD  3 —  AM  REBUILDING  SETUP. DAT  FOR  SALOGS') 
READ  (15, 5,END=100)  LINEl 
WRITE  (1,5)  LINEl 
FORMAT  (80A1 ) 

GO  TO  1 

TRANSFER  "TEMPI"  TO  "SETUP.DAT" 

100  CLOSE(UNIT=l 5) 

CL0SE(UNIT=1 ) 

OPEN (UNIT*1 5, DEVICK='DSICC',ACCESS='SEQOUT',KODE= 'ASCII', 

1  DISPOSE='SAVE',FILE='SETUP.DAT') 

OPEN (UNIT=1 ,DEVICE='DSKC' , ACCESS='SEQIN' ,MODE='ASCII  V. 

1  DISP0SE='DELHTE',FILE='TEMP1')  *>  ' 

REWIND  15 
REWIND  1 

110  READ  (1, 5, END-2 00)  LINEl 

WRITE  (15,5)  LINEl  < 

GO  TO  110 
200  RETURN 
END 
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ooo  non  in  w  oo 


c: 

c 

c 


suitKOii  i  i ci- 1  ion 


i.  ,  l  o' i  i>! I !).? , 

l  inr:;!:: 

Cuo-io  /  .  .  1/  :u;n  ; i*l : 

COMM-)  ./.t  i  l.i '  :  i.  o  ,i  ,  1. 1  .  i  (  ii)  ) ,  T  BLANK,  IAS  i K  v,  H \XL  I  , 

1  i.rino'!), 1  !>:• <,m  ...i  d,]:.;;>fii. 

common /\.  !'■:/  \'a:t ;■;(!.  ).  i :? ) ,ma ■::: •  m.maxnmi  ,maxnm2,maxnm3, 
1  man’.'m  yln,::,  •.>: if.:(  /o>  .'ciu 

COMMON'/*.'. >0.;s/  LS  ICON  (  1  00, 8)  ,  MU’ ICON,  NUHOUT,  MlIMfH,  MAXCON 
1  ICO LON 
C 

C  READS  [N  T’!i:  OKU AVIORAL  Model  FROM  SI. SC. DAT  AKl) 

C  ARRANGES  IT  FOR  SALOG3. 

C 

WR ITU  (2,1) 

UR 1TK  (5,1) 

1  FORMAT  ('  CKTMOJ)  2 —  AM  BUILDING  THU  SAI/OCS  FUNCTIONAL 

1  '  MODELS') 

GET  THE  NEXT  BLOCK  IN  THE  BEHAVIORAL  SYSTEM 

WRITE  (1,3) 

FORMAT  ('^MODELS'  ) 

NOUT=0 
NTOTAL-O 
OUTFLG--1 . 

CALL  LT.NEIN 

CHECK  FOR  EOF 

IF  (ENDFI1..EQ.  1.)  GO  TO  1000 
IF  (LT:.E ( 1 )  . EQ.  1HE.  Alii). LINE (2)  •  EQ.  1I1N.  AND. 

1  LINE(3).EQ.  1111))  GO  TO  1000 

PULL  OUT  THE  BLOCK  NAME 

MO  DC  N  T  -  -M  0  D  CL .'  T  F 1 
DO  10  m u:  11 ! : : I ~  1 , M  AXN A‘ I 

LINE  1  (Xl."!i!SII)--LTN-:  (NUIllISH) 

IF  (LJK'i:(MU:ilIS!I)  .EQ.  IBLAMK)  GO  TO  20 
10  CONTINUE 

IF  (LINE(MA”NM) .NE. I BLANK)  GO  TO  600 
NUMHSH--MAXNM  1 
20  Nl)MllSi!=NL'Mi!SII-l 

1PLACE---TFI  ND(NUMllSH) 

IF  (  1 1’LACi,.  EQ.O)  GO  TO  500 
1  DPNTR-  NUMHSIII  2 

WRITE  ( 1 , 22)  (NAMES ( I  PLACE, T) , 1  1 , MAXNAM) , 

1  (NAMES (LPLACE, l) , l-MAXNMI , MAXNMA ) 

FORMAT  ( HA  1 , '  O', 41 5,'  O') 

IDl’NT  1  IDFNTR 

IF  ().I  tli:(  I  DI'.NTR) .  Ell.  1  ASTRA)  WRITE  (3,105)  LINE 
IF  (LI  NK(  I  DI'NJ’R)  .  EQ.  I  ASTRA)  IDPNTl  -l 


I  01 


22 


I 


c 

C  CHECK  ALL  Till;  IDS  OF  Till:  GIVEN  BLOCK,  REMOVE  Till:  ; 

c 

30  CM, f,  NEXT  I  D 

i  f  ( 'lux.),  i :i ! -  L )  co  To  I  :-o 

c 

C  CASK  FOR  SEMICOLON 
C 

IF  (LINK (  L  1)1 NTR)  .NE.  ICOKO::)  GO  TO  100 
IF  (L1NK(J  ovTi’R+l  ).NK.  IliLANK)  GO  TO  700 
L I N  K  ( 1 D 1’NTiv )  =  I  BLANK 
OUTFLG~0. 

1 1)  PN  T  R= 1 1 )  I’: !  T  R+2 
IF  (IDPNTR.EO.  3)  NOUT-HTOTAL 
IF  (IDPNTR.KQ. 3)  GO  TO  30 
N  OUT  =NTl)TALT  I 
IDTABL ( 1 DPLAC , MAX ID1 )~1 
C 

C  CASE  FOR  ASTERISK 
C 

100  IF  (LINE(IOPNTR)  .NE.  IASTRA)  GO  TO  110 
WRITE  (3,105)  LINE 
105  FORMAT  (S0AJ) 

WRITE  (1,105)  (LINE(I) , I=IDPNT1, MAXLIN) 
IDPNT1=1 
C 

C  CASE  FOR  VALID  ID 
C 

110  NTOTAL=NTOTAL+l 

IF  (OUTFLG.EQ.l.)  IDTABL (IDPLAC,MAXID1 )=1 
IF  (OUTFLG.EQ.O.)  IDTABL(IDPLAC,MAXID2)=1 
GO  TO  30 

120  IF  (NOUT.EQ.O)  N1NPUT=NT0TAL 

IF  (NOUT.NE.O)  tIINPUT=MTOTAL-NOUT 
WRITE  (3,103)  LINE 

WRITE  (1,105)  (LINE(I) , I=IDPNT1, MAXLIN) 

WRITE  (1,123)  (NAMES  (I  PLACE,  I)  ,1=1  ,MAXNA11) 

123  FORMAT  (411ENO  ,8Al) 

IF  (NOUT.EQ. NAMES (IPLACE.MAXNMl ) . AND . 

1  NINPUT.EQ. NAMES (I FLAG E,MAXNM2) )  GO  TO  5 
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SAGE 
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I 

WL 

1TE 

(2, 

12 5)  :R)U!’,r’AM-: 

(IF 

i. ace, max:  •' 

i 1  ) , 

I  1 

1 

i  ■ :  ■  •  •  wv  • 
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'.MM 

! 

V; 

:  rr 
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125 

Ft 

i  * 1  f  A 

T  (' 

Gl.  H'D  1  W ' :  — 

r.:v 

ALIO  i.C  .; 

R  OF  OHTI'CT', 

| 

1 

* 

Ok  i::i\:r  lix:;: 

;  \\ 

X  THIS  i,),. 

MR',/,'  (ci vc.-:/' , 

f 

2 

* 

KEOUiREI).  .  .  .OF 

i'i'u  1 

-  ',2)5,' 

.  .  .  INFUT--  ',215) 

1  . 

CALL 

HALT 

1  , 

500 

N! 

1TE 

(2, 

501)  (L  f  N E 1(f) 

,T-  l 

, NUMHSH) 

501 


WRIT'-  (5,501)  (LIMIKl  (  1 )  ,  1-  1  .NNMiLSK) 

FORMAT  ('  CF.TMOD  501 —  BROCK  NAME  NOT  FOUND  IN', 
1  '  NAHMS  TABLE-..-  ' , 10A1) 


CALL  HALT 

600  WRITE  (2,601) 

WRITE  (5,601) 

601  FORMAT  ('  GETMOJ)  601—  IDENTIFIER  TOO  LONG') 


CAM,  HALT 

700  WRITE  (2,701) 

WRITE  (5,701) 

701  FORMAT  ('  GETMOD  701—  A  BLANK  ALWAYS  FOLLOWS  A  ;') 
CAL),  HALT 
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XT 
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I 


r 


i 


I 


i 


c 

c  ciir.c:;  idiaul  for  i:  uior.s,  :,h  ;i  •  •■.•'.kui.i-v  terminate  this 
c  koiiruv.  if  no  r-:’::v.r.  found. 
c 

looO  ---0. 

<;:■  i  (’,  1  ‘Y'W 
w !  ti:  (5,  1  On.'.  > 

1002  roiviA.r  (//  v::v.-.:;jn  ion.--  node  ;'VtE',5x, 

1  ,  V/l, ' !  ) 

DO  1010  i=t,tu"siZ 

IF  (IlViVuiUl,  l).v:Q.  IBEAfUO  OO  TO  1010 
UR  LTD  (2,  1003)  (IDT  ADI.  ( r  ,  J)  ,.1-1  ,MAXi U2)  ,T 
WRITE  (.3,  1003)  ,.I>,  1-1  ,  MAXI  02 )  ,  l 

1 003  FORMAT  (T 2,  FA  1 , 8X , 15, OX , 15, AX , 1 3 ) 

IF  (IDTALLd  ,MAXLU1)  .VXJ.  11)  TABL  (I ,  MAXID2  ) )  GO  TO  1010 
WRITE  (7,1001) 

WRITS  (3,1003) 

1005  FORMAT  ('  Gi. i'MOD  1005—  THE  ABOVE  ID  OOCS.Nf  HAVE  AN', 
1  '  INPUT  AND  OUTPUT  CONNECTION  ') 

ERRFLO-1 . 

1010  CONTINUE 

WRITE  (2,1020) 

WRITE  (5,1020) 

1020  FORMAT  (IX) 

IF  (ERKFLG.EQ. 1.)  CALL  HALT 

RETURN 

END 


J  0* 


1 


r 

c 

r: 


1  |!  "i/  •  . 


r  Yiiis  uou'i  i::\  r;->, vi  check  u,.  kicking  u r  i  dt.-j r iki in: 
c  /  v  i i!>  ■ »  <>  ■:.{  i •-  irvsov  ;ia r:i\\  r\-r;r:  s  r  ■ ; i  vi  s«j;:s  ; 

c  /.  ti:st  o:'  id  KVAi,. 

c 

cake  1. 1 

5  cam,  \ i : \ ’  id 

IK  (NO  1 1>.  co.  ! )  no  to  i 00 

IK  (|.i:;i;(i  ni'NTK)  •r;;.  I  COLON)  II)PrJTR=inrrlTK+2 
writ-:  (:>,  10)  (LiMi’i ( i  ),i-i,ir  :n>) 

WRITE  (’>,10)  (MNEi  (I)  ,  1*1  ,M’.XT») 

10  FORM  (T2,  U>.\). ) 

GO  TO  r> 

100  WRITE  (5,10!) 

101  FORMAT  ('  NO  MURK  IDENTIFIERS'  ) 

RETURN 

END 


n  n  o  »—  o  o 


c 

c 

c 

subroutine  conect 

c 

c.  •  :  Ki/i •:.':v;j,.j.(W0'\  10) ,  1  I'Piac.hv'.i  ui  ,w.\\t 

1  I  n;’s  V/. 

COMMON/:;  1 i . /  LINK (80)  ,us;:l  (80) ,  IBI.A:n:,lAST!<A,MAXLlN, 

1  L1NKND,  IDFNV  -..MAXLD.NOIU.L.NDFIL 

COM? ION /NODES /  LSTC0N(  100,  8)  , NUMCON,  NUMOU'L' ,NUMI  N , MAXCON, 

1  I COLON 
C 

C  PURPOSE  IS  TO  OPERATE  ON  THE  FIRST  SISL  PROGRAM  CARO. 

C  TUTS  CARD  SHOULD  UK  A  "CONNECT"  CARD  WHICH  LISTS  ALL 
C  Tin:  NODES  COMMON  TO  THE  SALONS  GATE  LEVEL  MODEL. 

C 

C  IN  ONE  SENSE  OUTPUT  MEANS  OUTPUT  FROM  A  BLOCK 
C  IF  A  NODE  IS  NOTED  AS  BEING  IN  THE  CONNECT  LIST,  IT  IS 
C  REFEEED  TO  AS  AN  INPUT  To  THE  SALOGS  GATE  LEVEL  MODEL 

C 

C  THIS  ROUTINE  WORKS  MUCH  THE  SAME  AS  GETMOD  AND  WAS  USED  AS  A 
C  MODEL  FOR  CREATING  IT. 

C 

C  FORMAT — >  CONNECT  OUTLIST  ;  INLIST 

C 

c 

C  MAKE  SURE  A  "CONNECT"  CARD  IS  THE  FIRST  SISL  COMMAND  CARD. 

C 

CALL  LINE IN 

IF  (LINE(l).NE.  I11C.0R.L1I:E(2).NE.  1U0.0R. 

1  LINE (3) .NE. IHN.OR. LINE (4) .NE. INN. OR. 

2  LINE(5).NK.  1HF..0R.  LINE(6)  .NE.  IRC. OR. 

3  LINK(7) .NE. 1UT)  GO  TO  500 

IF  (LINE(8) .NE. I BLANK)  GO  TO  600 
01TTFLG»I. 

NUMOUT=0 

NUMCON-0 

IDPNTR=9 

C 

LOOP  TO  GET  ALL  OF  THE  IDENTIFIERS 

I  CAL  ,  NEXT ID 

IF  (NOID.EQ.l)  GO  TO  400 
IF  (IDPNTR.GT. LINEND)  GO  TO  15 

CHECK  FOR  THE  OUTLIST/INLIST  SEPARATOR  (;) 

IF  (LINK(IDPNTR) .NE. ICOLON)  GO  TO  15 
IF  (LINE(  IDPNTR+l  )  .NE.  IiiLANK)  GO  TO  800 
OUTFLOW. 

1DPNTK~IDPN  TR+2 

IF  (  IDPNTil.Eii.  3)  NHMOUT -NUMCON 

IF  (IDPNTK.ME.  3.  AND.NUV.lM’.i. NE.  0)  I DTABL  ( ID Pl.AC , MAXID2  )  =  1 
if  ( idpntr.n::. 3. and.nemcdn.ne. o>  numoi.t^numcok  i  i 

IF  ([DPNTR.Lq.  3.0R. NUMCON.  El^. 0)  GO  TO  10 
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c 


C  PUT 

nu;  n>  mro  tul 

CONNECT 

LIST 

c 

1  5 

NUMCON  N!'‘ 

;co  ;<  i 

IF  tuSlN'I.i 

.  K'  i .  '  . 

)  T !)  P  '  !U 

(  1  s  s  AC. 

is  so, 

no  :mi  i  - 1 . 

,  'AS  i  !) 

• :  •"•:)  co 

||)  /OO 

20 

C 

LN'ICONI 

cor:  I :  iu'E 

[NMi. , 

i)A!:;:: 

:i  CD 

c  check  for  mrn.rcAT;:  ids  in  r:ii\  connect  list 

c 

CALI,  CONCUR 
CO  TO  10 
C 

c  detkkmi  where  tii-:  ouclist  ends  and  the 

C  INLIST  BEGINS. . .PERFORM  AN  INFO  DUMP 

c 

400  IF  (NUMOUT.  J'Q.  0)  KUKIN-rUlMCON 

IF  (NUMOUT.  N  DO)  NUHIN^NUMCON-llUMOUT 
WRITE  (2,410)  X O' !CON , NUMOi IT ,  NUMIW 
WRITE  (5,410)  NI" ICON , NUMOUT , NLC1IN 
410  for:; at  (/,'  codec  i:  4io--',/, 

1  '  TOTAL  #  NODES  COMMON  TO  SAL0GS=' , 110, 

1  /,'  OUTPUT  NODES  TO  SAL0GS=  ',110, 

2  /,'  INPUT  NODUS  FROM  SALOGS=  ',110) 

IF  (NUIiCON - KQ. 0)  GO  TO  475 

IF  (NUMOUT.GT.O)  WRITE  (2,415) 

1  (  (LSTCON  (T  ,  J)  ,  J:-l ,  MAN  ID )  ,  1-1 ,  NUMOUT ) 

IF  (NUMOUT.GT.O)  WRIT E  (5,415) 

1  (  (LSTCON  (I,J),.J-1  ,MAXID)  ,  I;-l  , NUMOUT) 

415  FORMAT  (//,'  ***  OUTLIST  ***',/, 100 (T2 , 8A1 ,/) ) 

IF  (NUMIN.CT.O)  N=N UMOUT+l 
IF  (NU'IIN.GT.O)  ROUTE  (2,420) 

1  ( (LSTCON (I , J ) , J-i , MAXI D) , 1=K, NUMCON) 

IF  (NUMIN.CT.O)  WRITE  (5,420) 
l  ( (LSTCON (I, J) ,  J=1 , MAX1D) , I -K, NUMCON) 

420  FORMAT  (//,'  ***  IN  LIS  T  ***',/, 100 (T2, 841 ,/) ) 

475  RETURN 
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c 

c 

c: 

i'll  ;!‘i  i.)’'! 

c 

«  ./•:*: i .  **  i  ■  '  1  '  .  I ;  t  •  ,  ' .  i  i'  •  \  >i 

1  I.i  ‘I,  ill:-  •  '  i  n.  j  :uj.  I  I, 

f:c  :  )-;/::a'v;/  ■:  ■  ■  . ;  .v\  i  :m  ,  max-;”?,  : 

l  ;•  .  ( 7u ; , :u:n!: 

c 

C  WILL  I»: -Vi;i  v»p  \  H.\s!l  KlWiiMl  ON  II!!:  1- 1 

C  CtMKAOi  '  "S  IK  DIN'  l  .  THIS  KOHlTi:  IS  !!::!•;>*  f  IR  SI.OOR 

c 

Ill  KIT  1-0 

DO  10  T=1 ,  NUMNSH 

IK  (dini: i  O  )  .>:o.  ibdank)  oo  to  ioo 
ICIliT=LINKl  (  f ) 

iBKfT  i-ichak  (ioiin)+i  o  i-i  !':a::na:t+ii’.kH  r  i 

10  CONTI MUE 

1 00  ID >U’T  1  "-MODU LO ( 1 ID'. I’T  L , MANNER) 

IHKi’UT-IBKPT  I 

RETURN 

END 


c. 

c 

(; 

!■  i ! .■■■;  i  n-;/-;  :  ( ;  ni'v:;v) 
c 


1  i  i  ■;  ic;  .  *  ;•  .  ■  ,  j  i, 

C“  ■  •  /!  '  ;/  li.1  (  I  Dili;,  nj,!  ,  i  ,  VAN  f  l) 

l  idi'.i:/ 

c 

c  hashes  -nil:  in  in  lint.i  tom  tiik  inrun.  array 

c 

I  PEACE-  L  i.’POT  (MAE  i  !) ) 

ICY.i.  ■'.) 

LIMIT  -  =  Hits  17, 

5  icvu.i-  :  l 

no  10  i-iplace, limit 

ik  ( 1 1 < pa i) ( i ,  ■ ; \x r i j i ) . t: .  ii;i,a;,’k)  go  to  5u 
00  7  j-1 ,M\XT  0 
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